So yes, I find myself in the dubious position of implementing a SwitchToThisWindow
call to force my window to the front. I agree, its not ideal, but its not always possible to argue against product "features" that others deem necessary.
Now, I consider SwitchToThisWindow
to be a win over the AttachThreadInput
hack to do a forced window switch as its less likely to deadlock, and should SwitchToThisWindow
be removed, or cease to function I won't complain.
However, SwitchToThisWindow
has the unfortunate side effect of pushing the current foreground window to the bottom of the z-order in addition to bringing the target window to the top when FALSE is passed for the fAltTab parameter, and not doing anything if TRUE is passed.
How can I avoid this 'push current active to z-bottom' behavior without resorting to AttachThreadInput
?
Alternatively, MS can just remove AttachThreadInput
as a viable workaround and I can just tell my manager that the impossible, is in fact, actually, impossible.