Why is my window unexpectedly becoming topmost?

A customer had a problem where one of their program's windows was somehow receiving the WS_EX_TOP­MOST extended window style, thereby becoming topmost. The scenario was that they created a popup window with the WS_EX_TOP­MOST extended style, and subsequently opened a document window. If they destroyed the popup window before creating the document window, then everything was fine. But if they created the document window before destroying the popup window, then their main app magically gained the WS_EX_TOP­MOST extended style. Their investigation revealed that nobody was calling Set­Window­Long with GWL_EXSTYLE and WS_EX_TOP­MOST.¹ Are there other ways that a window can become topmost?

One way that a window can become topmost is if it is created with the WS_EX_TOP­MOST extended style.

Another way that a window can become topmost is if you call Set­Window­Pos and pass HWND_TOP­MOST as the hwnd­Insert­After.

Yet another way that a window can become topmost is if you pass a topmost window as the hwnd­Insert­After.

Armed with this information, the customer did some more investigation and reported back: They found a call to Set­Window­Pos that was making the window topmost.

Mystery solved!

¹ Not that anybody should be doing that anyway. The documentation for the WS_EX_TOP­MOST extended style says that you shouldn't be manipulating the extended style bit directly. "To add or remove this style, use the Set­Window­Pos function."

Comments (8)
  1. Joshua says:

    I would expect that setting WS_EX_TOPMOST using SetWindowLong would result in some kind of crazy delayed-topmost behavior.

    Incidentally, turning on and off WS_CHILD using SetWindowLong causes surprising behavior; but not doing it when you need to causes more surprising behavior (abusing SetWindowParent to give an overlapped window a parent kind of works …).

    1. Joshua says:

      Correction; it’s called SetParent.

    2. Neil says:

      I think I tried doing that back on Windows 3.1 to turn a child window into a popup window although unsurprisingly Windows didn’t appreciate it and I switched to creating a dummy parent popup window instead.

  2. Paul Topping says:

    It seems a little confusing that a style (WS_EX_TOPMOST) is also a state value reflecting that the window is, in fact, topmost. This begs the question as to whether it is ever possible that a window have WS_EX_TOPMOST style without being on top.

    1. Falcon says:

      A topmost window can be behind another topmost window. So, all topmost windows are in front of all non-topmost windows, but there’s an order within each of those groups.

      1. skSdnW says:

        …and the third group reserved for the desktop/shell; bottommost.

      2. MarcK4096 says:

        And you get a bonus if you can figure out how to always keep your topmost window on top of all the other topmost windows. :)

  3. The_Assimilator says:

    For once, a customer that was not stupid or incompetent! I feel that the scenarios mentioned should be added to the documentation for WS_EX_TOP­MOST to help anyone else with the same potential problem.

Comments are closed.

Skip to main content