Wait. What?

Argh! Got into Windows yesterday morning, only to discover my sub expired. :/ It'll have to wait till next week as totally skint for the last two weeks but getting my monthly benefit next week Thursday.

That reminds me Jorge, could you please change the registration name to my user name here - it's just not safe having ones real name anywhere on a computer anymore! MTIA.

Done, sent.

As I said - when the workshelf is collapsed to just the headers you can still access the context menu (Right click on LHS of collapsed workshelf) at which point you can Disable Autohide. However if you do not then make the workshelf visible (i.e. open it), then the double click issue is observed when trying to open a desktop icon.

If the workshelf is 'open' (i.e. visible) then the double click of a desktop icon works as expected. Indeed if any application is visible on the monitor (e.g. this browser) then double clicking a desktop icon works.

Ok, this is huge, because so far I was convinced this had strictly to do with the dock, which has some very convoluted logic because of raising itself up and down on mouseover, etc...

It actually has nothing to do with either the dock, or shelves, or even directly with auto-hide.

It has to do with how WIN+D is detected, and what happens if the Winstep application thinks WIN+D is active.

You see, Windows does not send any message or fire an event when the desktop is raised. For a dock, etc, to remain on screen when the user presses WIN+D, the Winstep application must constantly monitor for this situation.

It does this by checking if the current foreground window is the desktop - but this is not enough, because clicking a desktop icon makes the desktop the foreground window (beginning to see the connection now?). So further tests are made to try to distinguish between a real WIN+D situation and the user clicking on the desktop.

The first test divides the screen into 16 quadrants and checks to see if a single point in the middle of each of those quadrants belongs to a top level window (one that would appear as a button in the taskbar) instead of the desktop. This is why the bug only happens when there are no windows open on the desktop.

The final test is a quick scan of the Winstep application own windows (docks, etc)... Again, it divides each of the visible windows (all open docks, shelves, etc) into a 4x4 grid and checks to see if any point in the middle of each grid belongs to our window (remember WIN+D "hides" all windows that are not "always on top"). And here is the problem: a dock that is currently visible will fail this test, but if it is currently hidden (see the connection to auto-hide?) then all the quick scan returns are points belonging to the Desktop.

But a shelf, unlike a dock, is still visible when collapsed, you might say... yes, but it will be a thin stripe of tabs. And as such, none of the points scanned in the quick 4x4 grid test might actually fall in the visible part of the shelf. This explains why turning auto-hide off while the shelf is still collapsed does nothing, and why the "bug" doesn't happen if the shelf is expanded.

Anyway, if the Winstep application fails to detect a visible window on top of the desktop (regardless of these actually existing or not) then it assumes the user has pressed WIN+D and, to make the docks, etc, appear above the desktop, it re-parents all these windows (makes the docks, etc, child windows of the desktop window).

This re-parenting is not detectable under normal situations, but if this is a false positive for WIN+D is is enough to cause the first click on the desktop to be ignored.

I'm trying to come up with an alternative way to detect WIN+D even if no windows are visible on the desktop (which can also happen if you have a single dock and the dock is currently hidden).

Interesting - so are you able to reproduce the effect now then?

If not - what is different about your setup?

No. The fact that this still happened when only the shelf is visible forced me to think "outside the box".

At that point, figuring out the thing that ticked all the boxes wasn't too difficult (like a light bulb going off in my head).



I don't have auto-hide enabled for the dock, so it is always visible (so the hit test always finds it). Likewise, the theme I am using for the shelf (or even a vertical side drawer I also use) might, by sheer luck and the shape of it, make the shelf be detected by the hit test even when collapsed.

I also have the option not to show icons on the desktop enabled and normally have a ton of windows open on the desktop, therefore I would basically never run into this issue with my type of usage.

Forgot the most obvious: my desktop modules are also always visible so the hit test would always find one of them - the second test would thus always fail to signal WIN+D was active (unless it was actually active).

The issue might look simple on the surface, but it’s anything but. Take the WIN+D shortcut as an example: there is no event, no Windows message, no notification of any kind that allows a third‑party application to know when the user has toggled “Show Desktop.”

And this isn’t an oversight.
It’s deliberate.

Microsoft has a long history of reacting to API abuse by restricting or crippling APIs that actually have perfectly legitimate uses. A classic example is SetForegroundWindow. Originally, it allowed applications to bring important UI to the user’s attention - alerts, password prompts, incoming calls, critical dialogs. But because some applications abused it to steal focus and interrupt the user, Microsoft responded by layering on restrictions, heuristics, and timing rules that made the API unreliable and unpredictable.

The result?
Good applications - those that genuinely need to surface UI at the right moment - are punished along with the bad ones. Developers end up resorting to increasingly fragile workarounds: synthetic input, timers, z‑order hacks, invisible helper windows, anything to restore behavior that used to be straightforward and user‑friendly.

This is the pattern Microsoft keeps repeating:

An API exists for a valid reason.

Some applications abuse it.

Microsoft clamps down globally.

Legitimate applications break.

Developers invent hacks to compensate.

The platform becomes less stable, not more.

So instead of solving the underlying problem, Microsoft creates a new one: instability, inconsistency, and a platform full of undocumented heuristics that developers must reverse‑engineer by trial and error.

At the core of this is a flawed philosophy:
Microsoft tries to babysit the user by preventing applications from misbehaving, instead of trusting users to decide which applications deserve their trust.

If an application abuses a privilege - steals focus, spams notifications, manipulates the shell - then the solution is simple: the user should stop using that application. Punishing the entire ecosystem by crippling APIs only drives responsible developers into convoluted workarounds and degrades the overall user experience.

In short:
Microsoft’s defensive restrictions don’t stop bad actors, but they do make life harder for good ones. And the platform suffers for it.

To work around the WIN+D false positive, here is what I had to come up with:

I create a 1×1 pixel, nearly fully transparent (99% transparent) “sentinel” window. This window stays alive for the entire lifetime of the application. Its only purpose is to act as a probe - an indicator of whether the desktop is truly visible or whether something else is sitting on top of it.

Here’s the logic:

When the desktop becomes the foreground window, that can happen for multiple reasons. The user might have pressed WIN+D, but they might also have simply clicked the desktop. Windows provides no reliable way to distinguish between these two cases.

So before running any of the other tests, I check which window is currently at the screen coordinates where the sentinel window lives.

If the window at that position is anything other than the desktop window, then WIN+D is not active, because if WIN+D were active, the sentinel window would have been hidden along with everything else, leaving the desktop exposed at that coordinate.

This avoids the false positive where the desktop becomes foreground simply because the user clicked it.

However, there’s still a catch:
The position of the sentinel window is critical. If it happens to sit over the taskbar, or over an always‑on‑top window, those elements are not hidden when WIN+D is pressed. In that case, the sentinel window would be obscured even though WIN+D is active, breaking the detection logic.

So the sentinel must be placed somewhere guaranteed to be covered by normal windows but not by the taskbar or any persistent topmost UI.

This is exactly the kind of hack developers are forced into because Microsoft refuses to expose a clean, intention‑revealing signal for something as basic as “the user activated Show Desktop.” And it mirrors the same pattern we see with APIs like SetForegroundWindow: legitimate use cases get crippled, developers invent workarounds, and the platform becomes more fragile as a result.

Techlobo, can you please download beta 4 of Winstep Xtreme from

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

and let me know if that finally fixed the problem?

Thanks in advance,

Well, beta 3 has been running perfectly well behaved all Saturday morning and early afternoon so far, and downloaded beta 4 now on Linux but easy to transfer, and hope to run that by Monday.

Never seen Techlobo's problem here, but then my setup on my standard account is anything but typical. And no auto-hide, no nothing.

Anyway, hope T's prob's resolved with that, at last.

That seems to have fixed it (based on some quick testing - I will monitor it over the next few days).

Well done Jorge!