FileExplorer Treeview and Listview (TreeListExplorer)

[WildByDesign]

5 hours ago, Kanashius said:

I noticed, that they are at the bottom, so I added something to remove anything below the last added item, when filling the treeview... maybe that fixes your problem.
I will put it here, until you confirm if it works, before adding it to the main post.

 I have only tested with the Example so far, but this seems to have fixed the issue with the HasChilds randomly showing up in the treeviews.

I noticed another issue in both 2.9.0 and 2.9.1 after some more testing. Specifically in the Example. The bottom-right listview fails to load approx. 20% of the time which is interesting because I noticed that it was happening when the HasChilds shows up. In 2.9.1, HasChilds is gone, but the listview in the bottom-right still fails to load 20% of the time. Clicking on anything in the top-right treeview still wont make the listview show up.

EDIT1: Caught the following in the console:

__TreeListExplorer_AddView $hListView failed: 2:50

 

EDIT2: I went back to 2.9.0 for some testing because I wanted to find out the correlation between the listview failure on the right side bottom and the HasChilds issue on both treeviews and the correlation is 100%. So there is some sort of relation between both issues. They only happen together at the same time. In 2.9.1, the HasChilds is hidden but the listview issue still occurs.

Edited March 16 by WildByDesign

[Kanashius]

That is very confusing to me... The Error __TreeListExplorer_AddView $hListView failed: 2:50 indicates, that the $hListView is not a ListView and is thus not added to the system $hTLESystemRight. This is tested by (shortened code): StringInStr($_WinAPI_GetClassName(GuiCtrlGetHandle($idListVIew)), "ListView") . This should only fail, if the ListView is somehow not created... I have no idea why that would happen just sometimes... Either it fails or it works... Otherwise my first thought would be: Is there some Multithreading stuff going wrong (That AutoIt does not support at least in the coding part) and even then...

What Version of AutoIt are you using? Maybe there is something in a beta, where they try multithreading so the listview is loaded later or something...

[WildByDesign]

37 minutes ago, Kanashius said:

What Version of AutoIt are you using? Maybe there is something in a beta, where they try multithreading so the listview is loaded later or something...

My AutoIt version is 3.3.16.1 and I'm running Windows 11 24H2 with latest updates.

I figured it out. It's a 64-bit issue. I always run your stuff with 64-bit AutoIt and never had issue. I just switched AutoIt to run the scripts with x86 and the issue is gone.

EDIT: You can test this by simply renaming C:\Program Files (x86)\AutoIt3\AutoIt3.exe to C:\Program Files (x86)\AutoIt3\AutoIt3_x86.exe and  C:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe to C:\Program Files (x86)\AutoIt3\AutoIt3.exe to temporarily test the scripts as x64 without having to reinstall AutoIt.

All of your previous UDF versions worked perfectly on x64. But it is definitely and x64 AutoIt issue.

Edited March 16 by WildByDesign

[Kanashius]

Ok, I found the issue.

It is a Bug, that was already found in the TreeView UDF. But it was only fixed, if the provided ListView was a ControlID and not a ControlHandle (like I use).
So for now, I wrote a custom _GuiCtrlTreeView_Delete method, that fixes that and I will report the bug.

Details:
 

Spoiler

 GuiTreeView.au3 (Line 435+)

If Not IsHWnd($hItem) Then $hItem = _GUICtrlTreeView_GetItemHandle($hWnd, $hItem)
If GUICtrlDelete($hItem) Then Return True
Return _SendMessage($hWnd, $TVM_DELETEITEM, 0, $hItem, 0, "wparam", "handle", "hwnd") <> 0

needs to be changed to

If Not IsPtr($hItem) Then 
    $hItem = _GUICtrlTreeView_GetItemHandle($hWnd, $hItem)
EndIf
Return _SendMessage($hWnd, $TVM_DELETEITEM, 0, $hItem, 0, "wparam", "handle", "hwnd") <> 0

The same Problem already occurred in Line 445+, but was only fixed, if the $hWnd was not a ControlHandle.

; Danyfirex founding
; If We Use IsHWnd It will always return false. So You will always call _GUICtrlTreeView_GetItemHandle and You will get the GUICtrlGetHandle issue that happens randomly
; So let's use IsPtr and remove GUICtrlDelete So we can always delete using the Control Handle.

This also explains the "hasChild" elements you had in your TreeViews before. They did not get deleted, but instead AutoIt tried to delete "random stuff" and sometimes that "random stuff" was the ListView.

By the way: You do not need to exchange the AutoIt.exe files to run as x64. A simple #AutoIt3Wrapper_UseX64=Y at the beginning of the Script is enough.

I hope that was the last issue for now. Thanks for the help, patience and testing @WildByDesign 

Edited March 17 by Kanashius

[WildByDesign]

12 hours ago, Kanashius said:

This also explains the "hasChild" elements you had in your TreeViews before. They did not get deleted, but instead AutoIt tried to delete "random stuff" and sometimes that "random stuff" was the ListView.

Thank you for getting to the root of the issue so quickly and for the fix. I am assuming that with your temporary/custom fix, I don't need to modify GuiTreeView.au3 now. Unless I use it for other projects, of course.

Do you know if this specific issue has the potential to cause a crash?

The reason why I ask is because, for quite a while now, I have had this very infrequent random crash that only happens when navigating the TreeView. It might happen after 2 or 3 minutes or it might not happen for 30 minutes. I haven't been able to figure out any details about the cause of the crash and it is quite rare, so I haven't dug into it deeper.

12 hours ago, Kanashius said:

By the way: You do not need to exchange the AutoIt.exe files to run as x64. A simple #AutoIt3Wrapper_UseX64=Y at the beginning of the Script is enough.

This seems to work if I run the script from SciTE or from VSCodium. But if I just run the script from Explorer, it will still run as 32-bit on mine. I probably need to reinstall AutoIt and select 64-bit as default for running scripts since that is what I prefer.

12 hours ago, Kanashius said:

I hope that was the last issue for now. Thanks for the help, patience and testing

I put in some time with 2.9.1 lastnight and also a lot of time this morning and I have found zero issues with 2.9.1. The filesystem reloads are incredibly fast, keeps the selection properly and keeps the folder(s) expanded properly if they already were. Everything is working really well in this latest update.

This UDF has reached perfection and will help many users who need such features.

You're welcome. I am always happy to help in whatever ways I can. I find it amazing how you hadn't touched the UDF in around a decade (because it got overlooked and never got the attention it deserved) and you rewrite the entire thing, make it very performant with thorough features and great stability/reliability, and within a few weeks of quick updates you've got something truly amazing. Thank you for everything and also congrats on what you have achieved with this.

TL;DR = This is too good!

Edited March 17 by WildByDesign

[WildByDesign]

I like the addition of filetype icons. I have some suggestions to improve it since a lot of filetypes are missing icons because they don't all have a DefaultIcon stored in that part of the registry.

1)

I feel like the default (fallback) file icon should be changed from:

_GUIImageList_AddIcon($hImageList, 'shell32.dll', 1) ; File-Icon

To:

_GUIImageList_AddIcon($hImageList, 'shell32.dll', 0) ; File-Icon

The one that you have set makes it seem more like the file is text or document related. However, I think that my suggestion better indicates a generic file of any type since it is more of a fallback icon now for when the registry doesn't have a DefaultIcon.

 

2)

I get an icon for .dll files since the registry (by default, I assume) already has a DefaultIcon for dllfile. However, some system file types do not have a DefaultIcon in the registry. One example is .sys kernel drivers. For example, Windows Explorer displays the same icon for .dll and .sys. Below is a simple hack to make .sys files use the icon from .dll:

If $sExt = '.sys' Then $sExt = '.dll'
    Local $sRegData = RegRead("HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\" & $sExt, "ProgID")
    If @error Then
        $sRegData = RegRead("HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\" & $sExt & "\UserChoice", "ProgID")
        If @error Then
            $sRegData = RegRead("HKCR\" & $sExt, "")
            If @error Then Return 2 ; Default file icon
        EndIf
    EndIf

It is just the first line that I added and it seems to work well. Maybe this technique can be used for other missing icons.

 

3)

Executable files are missing their icons. That is because they don't exactly have a DefaultIcon and use an icon that is stored within the binary.

• If you can pull the icon from exe files in a performant way without slow-down, this would be great
• If not, maybe a single icon can be set for all exe files

 

4)

Image files such as .jpg, .png, etc. don't show an icon on my system. I assume that the programs that I use aren't setting a DefaultIcon in the registry. Maybe the best and easiest method for this would be to set a single icon for all image file types. Otherwise, you would have to pull an icon from the program associated with the file type. Those registry entries do show the program associated and it's file path, but no DefaultIcon.

 

Anyway, these are just some suggestions that I think would greatly improve the filetype icons.

[Kanashius]

@WildByDesign

1. You are right, done
2. That is more of a workaround, I implemented support for basically any file, so .sys should be supported as well
3. Yeah, I added the extraction of .exe icons (for .url and .lnk files as well). I also added the __TreeListExplorer_FreeIconCache method. Because a lot of icons are cached now, with some special ones not only for extensions but also single files, it may become a little big (normally it should be fine, but who nows about extrem usage :D). So there is a possibility to clear it up. (I mean, how many .exe/.url/.lnk files can someone have?
4. Well, that should be fixed now.

Edited March 17 by Kanashius

[SOLVE-SMART]

Hi @Kanashius 👋 ,

could you publish your UDF on GitHub (your account), too?

I personally would love to see the UDF there, because it would help to see the progress which you and @WildByDesign made with the UDF (requests/questions, responses/answers, bug fixing etc). I learned a lot so far, but it's uncomfortable to took the newly edited code snippets to see the diff on my own. It would be way easier to simple walk through the commit history 😀 . What do you mean - is there a chance that you publish the code there?

---------------------

Besides that, thanks for this great UDF 🤝 .

Best regards
Sven

Edited March 17 by SOLVE-SMART

[WildByDesign]

13 minutes ago, SOLVE-SMART said:

It would be way easier to simple walk through the commit history

I agree. I run a diff with VSCodium each update to learn more and understand. But Github would be easier.

[Kanashius]

I did not use Github, because I didn't think it would get that many changes, to be honest
I did some commits with some versions I still had as BackUp and added everything to Github (link in the main post).
So you can see at least most of the Versions differences

 

[WildByDesign]

Instead of:

Local $hIcon = _WinAPI_ExtractIcon($sIconPath, $iIconIndex, True)

I get better results on my 125% scaling monitor with:

Local $hIcon = _WinAPI_ShellExtractIcon($sIconPath, $iIconIndex, 20, 20)

If we can somehow specify icon size, it would be best. Can that somehow use the $iIconSize variable?

[Kanashius]

Done

[WildByDesign]

One issue that I notice so far with the exe icons is that they all display a folder icon in treeview, but the listview shows the correct exe icons. This is using the Example script.

[SOLVE-SMART]

7 hours ago, Kanashius said:

I did some commits with some versions I still had as BackUp and added everything to Github (link in the main post).
So you can see at least most of the Versions differences

Thank you very much 😀 .

7 hours ago, Kanashius said:

I did not use Github, because I didn't think it would get that many changes, to be honest

I know exactly what you mean. Very often, when I publish code on GitHub (smaller private projects) or an GitLab (for my work), I instantly realize what is missing or people will give some hints 😂 . That's why it's always worth it (for me).

Best regards
Sven

[WildByDesign]

@Kanashius I found something that should be really beneficial.

First:

Spoiler

Local $tSHFILEINFO = DllStructCreate($tagSHFILEINFO)
        Local $dwFlags = BitOR($SHGFI_USEFILEATTRIBUTES, $SHGFI_ICON, $SHGFI_ICONLOCATION)
        _WinAPI_ShellGetFileInfo($sPath, $dwFlags, $FILE_ATTRIBUTE_NORMAL, $tSHFILEINFO)
        ConsoleWrite("---------"&$sPath&"--------"&@crlf)
        If DllStructGetData($tSHFILEINFO, 2)<>0 Then ; ignore missing icons (SystemIcon=0 equals Default file icon)
            ;_ToStringC($tSHFILEINFO)
            If DllStructGetData($tSHFILEINFO, 1)>0 Then
                Local $iIndex = _GUIImageList_ReplaceIcon($__TreeListExplorer__Data.hIconList, -1, DllStructGetData($tSHFILEINFO, 1))
                If $iIndex>=0 Then
                    $__TreeListExplorer__Data["mIcons"][$sExt] = $iIndex
                    Return $iIndex
                EndIf
            EndIf
        Else
            If DllStructGetData($tSHFILEINFO, 1)>0 Then _WinAPI_DestroyIcon(DllStructGetData($tSHFILEINFO, 1))
        EndIf

 

This code above causes blurry icons for .sys (and others) because the icons are being stretched on hi DPI. So I spent a lot of time searching for a solution. I found a solution for this part of the code but it might also help the rest too. The solution comes way back from user Yashied and it worked well in my testing.

_WinAPI_AssocQueryString($Ext, $ASSOCSTR_DEFAULTICON)

As a working script example, play around with this:

Spoiler

#Include <WinAPIReg.au3>

$SysExt = '.sys'

ConsoleWrite('(' & $SysExt & ')' & @CR)
ConsoleWrite('--------------------' & @CR)
ConsoleWrite('Type: ' & _WinAPI_AssocQueryString($SysExt, $ASSOCSTR_FRIENDLYDOCNAME) & @CR)
ConsoleWrite('Command: ' & _WinAPI_AssocQueryString($SysExt, $ASSOCSTR_COMMAND) & @CR)
ConsoleWrite('Executable: ' & _WinAPI_AssocQueryString($SysExt, $ASSOCSTR_EXECUTABLE) & @CR)
ConsoleWrite('Icon: ' & _WinAPI_AssocQueryString($SysExt, $ASSOCSTR_DEFAULTICON) & @CR & @CR)

$LogExt = '.log'

ConsoleWrite('(' & $LogExt & ')' & @CR)
ConsoleWrite('--------------------' & @CR)
ConsoleWrite('Type: ' & _WinAPI_AssocQueryString($LogExt, $ASSOCSTR_FRIENDLYDOCNAME) & @CR)
ConsoleWrite('Command: ' & _WinAPI_AssocQueryString($LogExt, $ASSOCSTR_COMMAND) & @CR)
ConsoleWrite('Executable: ' & _WinAPI_AssocQueryString($LogExt, $ASSOCSTR_EXECUTABLE) & @CR)
ConsoleWrite('Icon: ' & _WinAPI_AssocQueryString($LogExt, $ASSOCSTR_DEFAULTICON) & @CR & @CR)

$RegExt = '.reg'

ConsoleWrite('(' & $RegExt & ')' & @CR)
ConsoleWrite('--------------------' & @CR)
ConsoleWrite('Type: ' & _WinAPI_AssocQueryString($RegExt, $ASSOCSTR_FRIENDLYDOCNAME) & @CR)
ConsoleWrite('Command: ' & _WinAPI_AssocQueryString($RegExt, $ASSOCSTR_COMMAND) & @CR)
ConsoleWrite('Executable: ' & _WinAPI_AssocQueryString($RegExt, $ASSOCSTR_EXECUTABLE) & @CR)
ConsoleWrite('Icon: ' & _WinAPI_AssocQueryString($RegExt, $ASSOCSTR_DEFAULTICON) & @CR & @CR)

 

This seems like an easier way to get icon path. At least in the example of .sys, we should then be able to get the icon with:

_WinAPI_ShellExtractIcon($sIconPath, $iIconIndex, $iIconSize, $iIconSize)

And that should result in a sharp icon on any hi DPI display. As long as the user passed the $iIconSize at Startup based on their DPI, of course.

Let me know what you think. I don't have the skills to put it into your code.

EDIT: I was able to confirm that this method does successfully achieve sharp icons on hi DPI.

Basically, the result of:

$sIconPath = _WinAPI_AssocQueryString(".sys", $ASSOCSTR_DEFAULTICON)

Had to be split into two parts:

$sIconPath = "C:\WINDOWS\system32\imageres.dll"
$iIconIndex = "-67"

That was then happily consumed by:

Local $hIcon = _WinAPI_ShellExtractIcon($sIconPath, $iIconIndex, $iIconSize, $iIconSize)

 

Edited March 18 by WildByDesign

[Kanashius]

17 hours ago, WildByDesign said:

One issue that I notice so far with the exe icons is that they all display a folder icon in treeview, but the listview shows the correct exe icons. This is using the Example script.

I found it. The problem was using the extension instead of the path when retrieving individual file icons from the cache, which returned 0 (=folder icon) with not ".exe" present. But I checked correctly, if the path is in the cache, so it did not fail there...

Additionally I added your proposed _WinAPI_AssocQueryString(".sys", $ASSOCSTR_DEFAULTICON) as a possibility to retrieve the icon from the registry. So that is working now.
Thanks for your research into that

[WildByDesign]

16 hours ago, Kanashius said:

Additionally I added your proposed _WinAPI_AssocQueryString(".sys", $ASSOCSTR_DEFAULTICON) as a possibility to retrieve the icon from the registry. So that is working now.
Thanks for your research into that

You're welcome. And thank you for add that. It made a big difference for the sharpness of icons under HiDPI.

All of the icons retrieved now from exe binaries, ico, registry, etc. are all coming in sharp now with one exception. I spent a few hours lastnight digging into it. The ms-resource (Appx) PNG assets all come up blurry under HiDPI no matter what.

So I loaded up ProcMon to compare how Explorer loads Appx icons to how AutoIt with your registry method retrieves Appx icons.

Using .log, .ini and .ps1 file types as examples, Appx has the following type of assets:

Spoiler

04/06/2024  07:42 PM               586 inifile.targetsize-16.png
04/06/2024  07:42 PM               787 inifile.targetsize-20.png
04/06/2024  07:42 PM               884 inifile.targetsize-24.png
04/06/2024  07:42 PM            10,776 inifile.targetsize-256.png
04/06/2024  07:42 PM             1,192 inifile.targetsize-32.png
04/06/2024  07:42 PM             1,492 inifile.targetsize-40.png
04/06/2024  07:42 PM             1,880 inifile.targetsize-48.png
04/06/2024  07:42 PM             2,618 inifile.targetsize-64.png

04/06/2024  07:42 PM               364 txtfile.targetsize-16.png
04/06/2024  07:42 PM               446 txtfile.targetsize-20.png
04/06/2024  07:42 PM               434 txtfile.targetsize-24.png
04/06/2024  07:42 PM             3,862 txtfile.targetsize-256.png
04/06/2024  07:42 PM               581 txtfile.targetsize-32.png
04/06/2024  07:42 PM               763 txtfile.targetsize-40.png
04/06/2024  07:42 PM               891 txtfile.targetsize-48.png
04/06/2024  07:42 PM             1,121 txtfile.targetsize-64.png

04/06/2024  07:42 PM               662 ps1file.targetsize-16.png
04/06/2024  07:42 PM               871 ps1file.targetsize-24.png
04/06/2024  07:42 PM            30,022 ps1file.targetsize-256.png
04/06/2024  07:42 PM             1,444 ps1file.targetsize-32.png
04/06/2024  07:42 PM             2,338 ps1file.targetsize-48.png

 

 

When following a registry method like this:

@{Microsoft.WindowsNotepad_11.2412.16.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.WindowsNotepad/Files/Assets/inifile.png}

Your method (or maybe AutoIt) always returns full path + [filetype].targetsize-256.png 100% of the time for any file type.

Explorer always returns full path + [filetype].targetsize-20.png or occasionally occasionally full path + [filetype].targetsize-24.png if the 20 resource does not exist.

Keep in mind that my main DPI scaling is 125%, so 20 pixel icons is default. 40 would scale down fine too. But 256 wont scale down nicely for any DPI.

So I came up with a working fix for section: If StringInStr($sRegData, "@")=1 Then ; Handle urls with @{...}

I don't know regex, so I am sure you can do it much better and cleaner.

Spoiler

#include <Array.au3>
#include <String.au3>
#include <WinAPIFiles.au3>


        If StringInStr($sRegData, "@")=1 Then ; Handle urls with @{...}
            Local $iIconSize = $__TreeListExplorer__Data.iIconSize
            ;Local $sIconPath = _WinAPI_LoadIndirectString($sRegData)
            ;#cs
            Local $string = _WinAPI_LoadIndirectString($sRegData)
            ; $string returns as "C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2412.16.0_x64__8wekyb3d8bbwe\Assets\txtfile.targetsize-256.png" for .log files as example
            Local $aArray = _StringBetween($string, "targetsize", ".png")
            ; remove "-256.png" or other DPI scale from end of string (I don't know regex)
            Local $sString = StringReplace($string, $aArray[0] & ".png", "")
            ; add proper DPI scale back with "-" & $iIconSize & ".png"
            Local $sIconPath = $sString & "-" & $iIconSize & ".png"
            ; ensure that an asset exists in requested DPI
            Local $iFileExists = FileExists($sIconPath)
            If $iFileExists Then
                Local $sIconPath = $sString & "-" & $iIconSize & ".png"
            Else
                ; if not existing, fallback to original call
                Local $sIconPath = _WinAPI_LoadIndirectString($sRegData)
            EndIf
            ;#ce
            If @error Then $sIconPath = -1

 

The forum is not showing this code correctly so you will likely need to copy into a code editor to see it better. I put comments to explain. Basically it will find a matching asset to your DPI (set with Startup of treeview System) and is matching asset does not exist, fallback to original call so as to not fail.

This works well, despite my ugly code. I don't yet understand what call Explorer is using to get the proper sized PNG per DPI scaling. So this could be considered a temporary workaround for sharp icons until we can discover how Explorer gets it.

From ProcMon, this is AutoIt call which returns the 256 pixel PNG always:

Spoiler

HKCU\Software\Classes\Local Settings\MrtCache\C:%5CProgram Files%5CWindowsApps%5CMicrosoft.WindowsNotepad_11.2412.16.0_x64__8wekyb3d8bbwe%5Cmicrosoft.system.package.metadata%5CS-1-5-21-2132944913-3894426601-2088357866-1000-MergedResources-4.pri\1db87e950bbc6e9\f95e619b\@{Microsoft.WindowsNotepad_11.2412.16.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.WindowsNotepad/Files/Assets/ps1file.png}

 

This is Explorer call that returns proper PNG for DPI scaling (24 px in my case since 20 px not available for ps1file):

Spoiler

HKCU\Software\Classes\Local Settings\MrtCache\C:%5CProgram Files%5CWindowsApps%5CMicrosoft.WindowsNotepad_11.2412.16.0_x64__8wekyb3d8bbwe%5Cmicrosoft.system.package.metadata%5CS-1-5-21-2132944913-3894426601-2088357866-1000-MergedResources-4.pri\1db87e950bbc6e9\550dfbd7\@{microsoft.windowsnotepad_11.2412.16.0_x64__8wekyb3d8bbwe?ms-resource://microsoft.windowsnotepad/files/assets/ps1file.png}

 

For what it's worth, the only real difference is \f95e619b\ and \550dfbd7\. But I don't really understand the difference there or understand .PRI files in general. But that difference could be the key to the right sized icon.

[Kanashius]

@WildByDesign

Yeah, its a littlebit obscure, whats happening there... windows (especially the registry) is such a mess... no clean single solution, but instead a lot of random stuff mixed together that came to be over time...
I now take the file I get from _WinAPI_LoadIndirectString and read all files with the same name but a different number, sort them by size and pick the first one, that is equal or greater then the wanted iconsize (downscaling is normally better then upscaling).

Man, it shows how messy windows is, if the code to retrieve the icon for a file is the second largest function in my code...

[WildByDesign]

1 hour ago, Kanashius said:

Man, it shows how messy windows is, if the code to retrieve the icon for a file is the second largest function in my code...

It may be the largest function in your UDF, but you figured out a more logical and more efficient way of obtaining the sharpest icons than Microsoft has done.

1 hour ago, Kanashius said:

Yeah, its a littlebit obscure, whats happening there... windows (especially the registry) is such a mess... no clean single solution, but instead a lot of random stuff mixed together that came to be over time...

I lost some hours of sleep just trying to make sense of it. I still don't fully understand much of the Appx/UWP stuff. It's such a mess.

1 hour ago, Kanashius said:

I now take the file I get from _WinAPI_LoadIndirectString and read all files with the same name but a different number, sort them by size and pick the first one, that is equal or greater then the wanted iconsize (downscaling is normally better then upscaling).

This is absolutely brilliant, by the way. It makes perfect sense and the best solution for DPI scaling. Coding for DPI scaling is not fun.

Anyway, I have tested 2.9.5 thoroughly and I have no issues. The icons are all sharp under all of the different scaling factors that I have tested. You did an awesome job making sense out of this icon retrieving madness. Cheers!

[Kanashius]

Hey, thanks a lot for all the work you put into testing this and helping to find good ways to solve the problems. This UDF would have never been as good as it is now without you