Block double "switch to" in scroll

I couldn't reproduce it. What I tried:

• Open and maximize Notepad.
• Minimize it.
• Set "Middle click" to "Switch to".
• Double click on the Notepad taskbar item with the middle mouse button. (1)
• Minimize Notepad again.
• Check "Minimize/restore when mouse is over: Taskbar buttons".
• Restore Notepad by scrolling up aggressively. (2)

During my testing, in steps (1) and (2) (and in general) Notepad never became restored, only minimized or maximized.

That's strange. I had that even that on WinXP sometimes. Now I'm using Win8.1 and that was more offen with the left click. I could reproduce it wildly clicking on item. But I've set double left click to 0 and doesn't do that anymore.

Set "Middle click" to "Switch to".

I didn't say anything about middle click. Left mouse button already do it. Don't try to wildly press the middle button, cuz you can damage the mouse wheel.

Restore Notepad by scrolling up aggressively. (2)

Maybe try aggressively scroll down and up alternately. It probably won't happen immediately after first try. You need to do it for some time to occur. And when window became restored (not maximized) it stays that way, it won't maximize with that method so don't be afraid that you'd miss the moment and won't notice anything.

This bug is very annoying, cuz it might happen anytime, but if you want to reproduce it yourself it's not that easy lol.

Strange, but I still can do it with left button. Maybe for some reason if both commands "switch to" and "minimize" are mixed then they call another command "restore". But how it can be fixed?

What's your setup? How can I reproduce this?

There are no non-advanced options related to the left click. So please provide your relevant advanced options, and I'll see if I can reproduce it on my computer.

How can I send you my setup?

Well left click normally do "switch to" and when the window is active then it do "minimize". So that's the only explanation how this might happen. The same with scroll. Mouse scroll can be easily damage to sometimes scroll in opposite direction and some stuff.

Just tell me how you customized the left click. If you're saying that it happens without you customizing the left click, then it probably happens when the tweaker is not running, too. Is that right?

Yes.

I tried to reproduce it with Notepad both with a click and a mouse wheel, both on Windows 8 and Windows 10. I couldn't reproduce this.

Were you aggressive enough? You need to be very quick and try for some time. I wouldn't test it on win10, they could fixed it there lol. And try File explorer maybe.

The same effect happens when some application is restoring windows and at the same time I'm restoring it with left click on toolbar button. E.g. I or other application open url to open in the browser and I click at that moment on Waterfox icon and then it's restored un-maximized.

I don't know what makes that. I had that also in WinXP, do it's certainly a Windows bug or feature.

I think that maybe lowering scroll sensitivity could help. If it would only accept one scroll and then block next ones for a second or two then it wouldn't happen.

I could reproduce it. Looks like a bug of Windows, and I found a way to reproduce it programatically and reliably. Explorer uses the unsupported SwitchToThisWindow function to bring a window to front. If you call this function several times in a short interval, the window restores if it was maximized.

You can reproduce it with my winapiexec tool:

* Open Notepad, maximize, then minimize it.

* Run the following command:

winapiexec.exe u@SwitchToThisWindow ( u@FindWindowW Notepad 0 ) 1

Notepad will be restored, still maximized.

* Minimize it again.

* Run the following command:

winapiexec.exe u@SwitchToThisWindow ( u@FindWindowW Notepad 0 ) 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1 , u@SwitchToThisWindow $$:3 1

Notepad will be restored, and un-maximized.

I can guess why it happens. The second (or so) call still thinks that the window is minimized, and so tries to restore it. But once the window gets the restore request, it's not minimized anymore, so it interprets it as "restore from being maximized". So kind of a race condition.

That's how Windows work, and the best I can do is to add an artificial limit on the frequency of the SwitchToThisWindow calls. Since this is quite a rare situation, I don't believe it's worth the hack, which is not a complete solution anyway, and can lead to other problems such as worse responsiveness.

I could reproduce it. Looks like a bug of Windows, and I found a way to reproduce it programatically and reliably. Explorer uses the unsupported SwitchToThisWindow function to bring a window to front. If you call this function several times in a short interval, the window restores if it was maximized.

I'm glad you could find it.

I can guess why it happens. The second (or so) call still thinks that the window is minimized, and so tries to restore it. But once the window gets the restore request, it's not minimized anymore, so it interprets it as "restore from being maximized". So kind of a race condition.

Yeah, I thought it could be the case.

That's how Windows work, and the best I can do is to add an artificial limit on the frequency of the SwitchToThisWindow calls. Since this is quite a rare situation, I don't believe it's worth the hack, which is not a complete solution anyway, and can lead to other problems such as worse responsiveness.

Well, as an advance option it shouldn't harm anyone. So I hope you'll add it.

Actually it's very easy with file explorer. When I scroll up the furthest I can on minimize explorer it unmaximize the window without a problem. With other windows it's not that easy though.

Yes, it seems to fix problem with scrolling. Thanks a lot.