14

If my window has the 'always on top' extended style set, I would expect it to be on top of all windows that do not have the 'Always on top' style set and those windows that have the 'Always on top' style set but were activated before my window was activated.

To test this feature, I open the task manager window - set it to always on top and then I open my window (myWindow).

In Windows 7, I observe the expected behaviour - myWindow comes on top of the task manager.

However, in Windows 10, that's not the case. The task manager is 'always on top' of other windows, even if those windows in themselves have the 'always on top' style set.

Is there something special that they are doing with the task manager in Windows 10? If yes, is there some work around for bringing my window on top of the task manager? I have tried simply using the BringWindowToTop function, but that doesn't work. Neither does setWindowPos with HWND_TOP as a value for hWndInsertAfter argument.

TheBlueNotebook
  • 1,204
  • 3
  • 15
  • 35
  • To further test things, I created two windows with the 'always on top' extended style set and I could one on top of the other based on which window was activated last. – TheBlueNotebook Aug 31 '16 at 10:06
  • 1
    Yes, Task Manager is special. You don't get to be on top of it. – David Heffernan Aug 31 '16 at 10:21
  • 2
    Take a logical leap: [What if two programs did this?](https://blogs.msdn.microsoft.com/oldnewthing/20050607-00/?p=35413) (plus [Practical exam](https://blogs.msdn.microsoft.com/oldnewthing/20101125-00/?p=12203)). If that thought experiment (and practical exam) didn't convince you, here is another look at the dilemma you are trying to create: [How do I create a topmost window that is never covered by other topmost windows?](https://blogs.msdn.microsoft.com/oldnewthing/20110310-00/?p=11253). – IInspectable Aug 31 '16 at 10:27
  • @DavidHeffernan Could you point me to any reference for that? Because You can be on top of the task manager in Windoes 7. So I am curious, as to why was this changed? – TheBlueNotebook Aug 31 '16 at 10:33
  • 2
    @IInspectable I have taken the 'logical leap' and done the thought experiments already. Windows as of now, allows for setting an 'Always on top' style to a window - which means there is some expected behaviour when two windows have 'always on top' style set. I am observing that this expected behaviour is not being met if one of the windows is 'Task Manager' AND if the OS is Win 10 (maybe Win 8/8.1 as well) – TheBlueNotebook Aug 31 '16 at 10:36
  • I don't think there are references to this. I think that this is a system component that gets special treatment from the system. When the task manager demands to be on top, it gets to have its way. You on the other hand, cannot subvert that. You don't get to use this special feature that task manager can use. – David Heffernan Aug 31 '16 at 10:37
  • 1
    [WS_EX_TOPMOST](https://msdn.microsoft.com/en-us/library/windows/desktop/ff700543.aspx): *"The window should be placed above all non-topmost windows and should stay above them, even when the window is deactivated."* - That has been true and still is. I don't know why you have other expectations than those documented. – IInspectable Aug 31 '16 at 10:52
  • 1
    @IInspectable Again, my question is for the case when two windows have the WS_EX_TOPMOST style. Say I set my application window with WS_EX_TOPMOST and another application has the same flag set, now if the two windows happen to overlap each other, which window should come on top of the other? My expectation was the window which was activated most recently will come on top. My expectation was being met in Windows 7 - but not in Windows 10. Hence, I wanted to understand what's different in Windows 10. – TheBlueNotebook Aug 31 '16 at 11:17
  • The problem is in between your keyboard and chair, not the OS. The changes in behavior are in line with the documented behavior (see the link I posted in a previous comment). Your options going forward are: `1` Stop expecting non-contractual behavior. `2` Find official documentation that promises to meet the behavior you expect, and file a defect report with Microsoft. – IInspectable Aug 31 '16 at 11:24
  • 1
    I think you'll just have to accept that the system designers place the task manager above your window. Is that really a hardship for you? Your users will just minimise or move or make not top most or close the task manager when they want to see your window. Not exactly a challenge. – David Heffernan Aug 31 '16 at 11:35
  • @DavidHeffernan Yup. It's not really a hardship. I just wanted to confirm the elevated status for task manager in Windows 10 before I give up on the problem and I was finding it hard to find any official references for it - so just wanted to confirm on SO if someone else has had similar experience and/or references that could help me. – TheBlueNotebook Aug 31 '16 at 11:38
  • I've not found any references, but the behaviour you describe exists. I've just surmised why I think it is that way. – David Heffernan Aug 31 '16 at 11:41
  • 4
    If you are looking for a more on-toppiness window then run osk.exe. It has no trouble staying on top of the task manager window :) In the olden days it would fight with any other window that wanted to be more important, pushing itself back into the foreground. The Win10 version probably uses the DWM, same kind of feature that draws the rectangles when you use Aero snap or use a touch screen and see your finger prints back :) Not otherwise well documented. – Hans Passant Aug 31 '16 at 15:15

2 Answers2

23

From a small research that I did a while ago:

  • The Task Manager is indeed a "special kind" of Always-on-Top.
  • The Task Manager window is being created with the following undocumented function: CreateWindowInBand.
  • Trying to use this function from another process results in ERROR_ACCESS_DENIED. Perhaps only a signed Microsoft process can use it.

2020 update:

A detailed writeup about the functionality was published here:
Window z-order in Windows 10

Mitch
  • 21,223
  • 6
  • 63
  • 86
Paul
  • 6,061
  • 6
  • 39
  • 70
  • Any ideas on how can I figure out if a particular window is indeed the "special kind" of top, given I have its window handle. Probably, the way you arrived at the conclusion that task manager is created using `CreateWindowInBand` might give me some hints here? – TheBlueNotebook Oct 04 '16 at 10:44
  • 2
    @TheBlueNotebook try `USER32.GetWindowBand`. – Paul Oct 04 '16 at 13:15
11

There were lots of changes made to the Task Manager in Windows 8. It would not be at all surprising that among those changes was special-case code to ensure it was always on top of all other always-on-top windows. Microsoft would not be breaking any contractual guarantees by doing so, since the Task Manager is a built-in part of the operating system. It is free to do as it likes with OS components.

To answer your actual question, there is no documented API for this. WS_EX_TOPMOST is the best you get. It's meant as an aid for the user, not a way to etch your app's window in their retinas.

When two different windows have this style set, the behavior is implementation-dependent. The only guarantee that you get is windows with the WS_EX_TOPMOST style are always on top of other windows without this style in the Z order. The system is otherwise free to resolve conflicts as it sees fit, including keeping the most recently-active topmost window on top, breaking the tie by forcing windows belonging to system components to the top, or even punishing processes that have more than one window with this style by forcing their window(s) to the bottom of the "topmost" stack.

Related reading:

41686d6564 stands w. Palestine
  • 19,168
  • 12
  • 41
  • 79
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574