@winstep thank you very much for detailed explanation!



No, just icons in general, like on attached screenshots. You see "Open dialog" windows on both screenshots, one when run from any other 64bit program, other when run from nexus. I guess it happens because I use Windhawk redirect mod, so it doesn't actually modifies dll/res files, but redirects them on registry level I think. Need to test how Nexus shows those icons when res/dll files are actually replaced.



Earlier one, can't test with the current version unfortuantley, as I don't own ARM device currently to test it.

Yes. If Windhawk is a 64 bit app, it cannot attach itself to 32 bit applications nor the 32 bit part of the Windows system. I guess that is what is happening there.

Love it when the pieces of a plan all smoothly fit together in the end, in a way much better than anticipated.

So, I added *64* new Windows 11 style icons to the

C:\Users\Public\Documents\WinStep\Icons\Samples\

folder (which contains most of the icons used for the internal commands) and removed the icons that are not used anywhere by the application (the latter will only affect new installations).

Previously the folder had 151 icons, now it has 148. Despite all the new Windows 11 icons being 256x256 (unlike most of the old icons that are 128x128), the size of the folder has remained basically the same, i.e. it only went up from 2.39 MB to 2.96 MB.

So, that is the first plus.

Most of the icons thus have a Windows 11 version (ending in *_11.png) and a non-Windows 11 version (same filename, but without the *_11.png termination).

The application will automatically use one set of icons or the other based on the new 'Use Windows 11 style icons' setting located in the More dialog of the General tab in Preferences.

Until now when you added an internal command (IC) the application would automatically fill the Icon Path field with the associated icon in the Samples folder. If for any reason the icon path field was left blank, the IC would then display the application icon.

So at first I thought that I would have to automatically change the icon path of every IC item in docks, etc, every time I switched the style of the icons, but then it occurred to me that I did not actually have to fill the icon path whenever the user added an IC, I could simply leave it blank and the application would retrieve the proper icon based on the IC type (and not having to specify icon paths would also mean smaller backup files, another plus)

This would allow me to use either style of icons "on the fly". At first I assumed that for this "on the fly" selection to work, the icon paths would have to be blank, which would mean irreversibly changing user data when the new version was run for the first time, something I did not want to do because there is always the chance the user is trying out the new version but ends up going back to a previous version (which would then display the generic application icon for all the ICs since old versions do not know how to retrieve icons for ICs "on the fly").

Turns out the solution is quite simple, and does not require touching user data: when retrieving an icon for the IC, if the icon path points to the older style icon BUT the new Windows 11 icon style is selected, then the application internally replaces the icon with the new style but without actually changing that item's icon path.

This means users can go back to an older version of the application without problems and that restoring old backups does not suddenly show old style icons despite the new icon style being selected (and so on).

Also, ICs can still have their icons customizable by the user, and in that case the IC will always show the user's icon regardless of the current icon style.

So, in the end it could not be better!

Ah, this "Windows 11 style" setting is not only going to affect ICs, it is also going to affect things like the icons used for Grid Stacks, some of the iconic modules, etc...

Windhawk is a 32 bit app, hence I'm surprised why this happens.

Might be using a 64 bit DLL?

Possibly, that would explain why it works the way it works.

While messing around with the external icons (i.e. icons not embedded into the executable itself) for the internal commands I think I may have finally understood a mystery that has been bothering me for quite some time now.

From time to time I would get a report in the Winstep Uninstall Survey of icons in the dock turning into question marks. Unfortunately none of the users who complained about this issue left an email address I could use to contact them later.

This was driving me crazy as I could not see what might be possibly causing this. Now I think I know:

If a user deleted his Samples folder thinking it was unnecessary, all the internal command items in their docks would turn into question marks. Since icons are cached in memory this might not happen immediately, only once the application was restarted or the user went into Prefs to change a theme or a setting. Given the delay he might not associate the icons turning into question marks to him deleting the Samples folder, thinking instead it was a bug in the application.

From now on if they do that they will get the general application icon instead of a question mark. Perhaps I should make a specific IC icon, embed it into the executable and use that instead if the Samples folder has been deleted.

Something like the two examples below to represent an Internal Command (IC). Someone let me know which of the two examples they like better, the idea being using the same metalic material used for the Winstep, NextSTART, WorkShelf and Nexus logos (also keep in mind you would only see those if you delete the Samples folder lol). My vote goes for the brushed metal since it's more "visible" at smaller icon sizes.