For those who are interested in these type of things:

Some who only updated to the new version 20 hours or so later may not even have noticed, but v25.7 had to be re-released due to two critical bugs/issues:

1. Right-click context menus may fail to appear in some cases.

2. Minimized applications might disappear from the Windows taskbar.

Two very distinct issues with very different causes, and the second issue might actually have been present in v25.6 as well.

So, why weren't this issues detected before the official release? The answer is simple: neither of them happened here or on the Windows VMs the applications are tested under before a release.

The second issue I can't even reproduce here, it's probably OS specific or specific to certain system configurations - but fortunately I was able to guess what caused it.

In fact, I had already been warned about it in v25.6 and although I thought I had fixed it already (and did, for that particular user), apparently all my previous "fix" did was reduce the systems where this bug reared its ugly head even further.

Still to this day, even though I know what causes it, I do not know WHY it happens in some systems but not others. It certainly did not in any of the systems I have here.

The bug was caused by the addition of a system wide event hook to detect when UWP apps are cloaked and uncloaked, so I didn't actually have to enumerate all currently open windows every x seconds which is a costly operation (you might not know this, but there are HUNDREDS of windows open at any given time in your system, and only a very small selection of those are visible).

For normal Win32 windows the system can (and does because I ask it to) notify the application via a shell hook when new windows are created, destroyed, maximized, minimized, etc... This means I do not have to poll every second to update the list of running applications.

But the windows of UWP apps are "different" (bloody snobs! lol) and they are not created and destroyed, instead they are hidden (cloaked) and un-hidden (uncloaked) and for whatever reason (perhaps because it no longer cares) Microsoft does not include these events in the Shell Hook.

So, previously I was polling/enumerating the list of windows in the system every 5 seconds or so just because of the UWP apps. To prevent this and while trying to optimize execution speed in v25.6, I decided to use an event hook together with the shell hook just to detect the EVENT_OBJECT_CLOAKED and EVENT_OBJECT_UNCLOAKED events.

When any of these two events was detected, the WINEVENTPROC callback function would "forward" these events to the message handling window proc as if they were window create and window destroy notifications from the shell hook.

This worked very well and so I no longer had to enumerate all system windows only because of the UWP apps.

But here is the problem: unlike a shell hook, where a user-defined message is sent to a window procedure so it is very safe, a event hook is a very different animal that is called directly by the system and if badly written has the potential to wreak havoc with the rest of the system.

So, it turns out that even though it did not cause any issues here, it was a VERY BAD IDEA for my event hook callback routine to forward the events to my message handling window by calling the window proc directly.

As I said, I still don't know exactly why, but on some systems this had the side effect of making minimized windows disappear from the taskbar (not nice!).

So now instead of calling my message handling window procedure directly from the event hook, I simply POST a message to it. This is 100% safe, makes the event callback proc as simple and as quick as it can possibly be and works just as well (why didn't I think of it before is anyone's guess).

Anyway, this solution should have fixed the problem for good and for all systems.

As for the right click context menus not appearing, this too had to do with another change I made to the code. It is a bit more complicated to explain, but when the menus played their opening animation (e.g. fade in, slide right, etc) they did so from the menu creation routine. This animation could be interrupted and therefore the user could actually click another item in the dock which would open a second menu and close the first one.

But because the first one was still in the middle of playing the open animation, this would cause issues internally (nothing the user would normally see but...) and had the potential to mess with the internal menu lists, who knows, even leading to an Access Violation error.

So I fixed it by decoupling the animation from the actual menu creation. This had the problem that the menu would "pop up" whole before the animation would actually start. Not good. So I simply "hid it" (to put it simply) until the animation triggered in a separate event a few milliseconds later. The animation routine would then show the first frame of the animation and all would be well. If the user tried to open another menu in the mean time it was ok and the animation might not even play (or could simply be interrupted with no ill effects).

So this worked well here, but I completely forgot (my fault!) that users can disable animations either for the menus themselves or globally. And if they did, then the menu animation routine would never be called and therefore the menu would remain hidden "forever".

The only reason this affected some users running the free version of the Nexus dock and Nexus Ultimate (where the menu opening animations are fixed and you cannot change them, unlike in Winstep Xtreme) was because they had disabled animations globally.

Still, being completely unable see the right click context menus pretty much made the application unusable and therefore the bug was deemed critical and the decision for a re-release was made (which would also fix the event hook issue).

Sigh. And I keep eating humble pie on v25.7.

Just finished releasing an update to the initial v25.7 release of the NextSTART component of Winstep Xtreme.

This update resolves an issue where NextSTART would crash and exit with a Type Mismatch error when attempting to move Quick Launch items via drag and drop.

The issue was introduced as a side effect of extensive code changes made to ensure full compatibility with DBCS (Double-Byte Character Set) languages such as Korean, Japanese, and Chinese.

In this case while before a Unicode string was passed as an argument to a shell function, when adding DBCS support this argument was changed to be a POINTER to a Unicode string (this avoided the DBCS -> Unicode conversions which were actually corrupting the characters).

I thought I had updated all occurrences in the code where this change took place and assumed that if I had forgot any the compiler would warn me about the string vs long type mismatch when compiling. As they say, assuming makes an ass of you and me.

Turns out I was wrong, the compiler did not flag this obvious mismatches and therefore a run time error would occur when attempting to pass a string where a pointer to a string was expected.

My sincere apologies for the inconvenience of having to download an update yet again... in my defense it is very hard to spot all bugs when making such extensive changes to the code as those that have been made lately.

Ah forget the humble pie Jorge, no need for that, shit happens, pardonnez mois mon Anglais, as the French say. And this did involve very extensive changes to the code. But it does raise the point that in the past, everything used to be thoroughly beta tested - I mean in general, not just here - and then perhaps a 'release candidate' before final release. Lot to be said for it, I reckon.