Nasty gotcha: Positioning your window beneath a topmost window makes it topmost
There’s a nasty gotcha with the DeferÂWindowÂPos function, and therefore any functions built on top of it, such as SetÂWindowÂPos: If you specify a hwndInsertAfter, and the insert-after window is topmost, then the window being positioned will be placed immediately after that window.
So far so good.
The hidden gotcha is that the window will be placed in the same zone as the insert-after window, which is the topmost zone.
In other words, the window will be made topmost, even if it wasn’t topmost previously.
Which is probably not what you were expecting.
Light
Dark
2 comments
I hear about these kinds of weird things often enough that I’m starting to feel like all software teams should have a dedicated person whose job is entirely nothing but to just tell them when they’re doing something the user (whether said user is a programmer or an end-user) is going to find unexpected or confusing.
But, is it really unexpected? It’s the behavior I would expect. Consider an airplane waiting to board, with two classes, “first” and “coach”. If the gate agent says “go to the back of the first class line”, it’s not the same as “go to the front of the coach line” (particularly if more first class passengers arrive after you).
f you are positioning your window immediately behind the topmost window, then your reference is to the bunch of top-most-ish windows, not to the plain-ish windows.