|
Decades ago MS added an "always on top" attribute you could give to a window your app creates so you could have a window that was always floating on top of everything else. If you dragged another window over that area, you could see the window being dragged slide "underneath" it rather than on top of it as you would otherwise ordinarily expect.
These days you rarely see apps using this attribute, but I don't believe there's anything in more recent versions of Windows to prevent you from using it.
For the past couple of years (and it's been this long before I decided to ask, just now) I've noticed a few apps that should never have this attribute, or at least have never presented any option to make it top-most, seemingly randomly get this attribute out of nowhere, and it stays that way until you close the app and restart it.
I have an old version of a news reader (as in Usenet) that does this every once in a while, and I've also seen remote desktop sessions do it also. Once the window somehow decides it's going to always be on top, I can't bring other windows in front. None of the apps I've seen exhibit this behavior have any option to turn this on or off, and I can't imagine any sort of criteria where code in an app might turn on the always-on-top attribute.
Am I speaking total non-sense, or has anyone else ever seen this?
[Edit]
I've done a quick google search, and while there are apps that apparently people use to make any app top-most, I absolutely, positively, have never downloaded such apps...and as far as I know there's no magic, secret key combination built into Windows to do that either.
|
|
|
|
|
[Original]
Some of those window attributes could be tied into the window class which would make it immutable, but I have seen apps that allow it to be toggled.
On a hunch, I googled if there is a system hot key for this and some post mentions Ctrl + Spacebar as a toggle. Which is an oft used hot key in my IDEs.
I will have to try it later.
[Update follows]
It looks like window class was for old 32 bit API from another poster. Different poster has/had good good info on SetWindowPos(ition) API which is newer from Vista+.
I think the hot key was app specific, I could not get it to work with Notepad. (Notepad could still be win32?)
I put a newer post at the bottom with a better reference.
modified 15-Oct-22 13:57pm.
|
|
|
|
|
I had a hook function that made that back in MFC times 
Random behaviour can also be caused by a conflict : if two windows have the attribute set, which of them wins ?
|
|
|
|
|
|
Yes, I have the technical understanding and have created such apps decades ago.
What I'm saying is that the attribute "randomly" gets applied to applications for no apparent reason, when said app had already been running for many minutes/hours/days.
|
|
|
|
|
I have apps that run for weeks and have never seen that occur.
|
|
|
|
|
For sure. There's no reason whatsoever an app should suddenly start doing this no matter how long it's been running for.
|
|
|
|
|
I've actually created such an application!
It was WinForms and VB.NET I think, probably .NET 4.5 or something.
I may have used that attribute you mention, but I remember it not always working.
For my application is was absolutely necessary that it worked.
First off, this was an application for factory workers using a touch screen (no physical mouse or keyboard).
The app opened full screen and the only way to close it was by closing it with a button (not the default Windows buttons, because I disabled those).
The thing is, they needed an on-screen keyboard.
The Windows on-screen keyboard was too small and had to many options for these simple workers (who would no doubt use it to mess things up), so I rolled out my own.
Since I created a sort of "factory application" framework, which we were going to use for multiple forms and applications for different customers, it all had to be quite generic, as to be reusable.
And "make sure you design your forms so a keyboard could popup at any time" isn't very generic, so the keyboard had to float above all else.
If the keyboard disappeared for whatever reason, you got stuck because there was no way to input anything.
So I made it always on top (not the application, I think, but that specific form).
Things even worked in design-time.
Colleagues could add buttons and "widgets" to a form similar as to how you add columns to a DataGridView.
They'd all look the same and every form had a similar look and feel, even though it was all custom software with very different functionalities.
Probably one of the hardest things I've ever programmed.
After some hacks to get the keyboard always on top it worked wonderfully well.
They're still using it now, 10 years later.
It was fun to make too.
I could spend my free time on it and I got paid double hours.
That way, they kept development in-house and I could still work on my regular projects, while having fun with this and making extra money.
I even worked on it during Christmas.
A new manager called me in after Christmas and started asking about my relation with my parents.
I was like "It's good... Where are you going with this?"
"I see you worked during Christmas."
"Yeah, I spent half a day with family and after that I was just having fun and making money!  "
Ah, good old times.
|
|
|
|
|
The cynic in me would just reply "cool story, bro", but that was, in fact, a cool story.
I know exactly how to do it, but the mystery in this case is how on God's Green Earth are random application windows getting that attribute when they don't (shouldn't?) even have code to do so. Like bits are flipping around randomly for no reason. Only, once it gets set, it never gets removed - unless I restart the app...
|
|
|
|
|
After I wrote all that even I was like TL;DR
dandy72 wrote: I know exactly how to do it, but the mystery in this case is how on God's Green Earth are random application windows getting that attribute when they don't (shouldn't?) even have code to do so. Like bits are flipping around randomly for no reason. Only, once it gets set, it never gets removed - unless I restart the app...
if (!alwaysOnTopSet)
{
_alwaysOnTopSet = Random.Next(10) == 0;
}I thought you knew exactly how to do this 
|
|
|
|
|
Smartass. Have a 5!
|
|
|
|
|
There's been a big change in how UIs behave which is that previously the user had control and would not be interrupted by the OS, processes or notifications - the user always had focus.
Nowadays, the user is just seen as one process and that process can be interrupted, have notifications pop up over a cursor or mouse pointer and be interrupted at any time - the user has become the slave to the machine.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Well that's arguably a good thing, since Windows is a multi-user OS. Even though you could also argue that since every user has his own desktop, he should still own it and other users running their own things at the same time should not have any influence on what gets shown on each user's screen...
|
|
|
|
|
GuyThiebaut wrote: the user had control and would not be interrupted by the OS, processes or notifications
I have been using tools that frequently created error reporting dialog windows consistently at the bottom of the window stack - it could even be obscured by its own main window! The dialogs were modal, blocking the application from execution, until by accident or luck moved other windows to discover that there was a new window down at the bottom demanding my attention and action.
It really was a pain in the lower part of the back. I hated it. If an application requires me to take an action for it to continue, it should call my attention to it, one way or the other. Equally bad is if the notification or error dialog pops up a large, centered window, immediately grabbing keyboard, mouse and other inputs in the middle of a word that I am typing, or the dragging of an object. There is a middle ground, e.g. a flashing icon in the taskbar. But I prefer a dialog on top that does not grab focus (and preferably not centered) to a window at the bottom of the window stack.
The ideal would be an option to put the window as the second one from the top, so that it won't obscure the one currently having focus, with the default/automatic placement algorithm ensuring that a significant part of it sticks out from under the currently active window.
|
|
|
|
|
Here is an AutoHotKey script to toggle topmost. It may be able to disable the feature for you if you use AHK:
; possibly from http:
!`:: ;Alt `
WinGet, currentWindow, ID, A
WinGet, ExStyle, ExStyle, ahk_id %currentWindow%
if (ExStyle & 0x8) { ; 0x8 is WS_EX_TOPMOST.
Winset, AlwaysOnTop, off, ahk_id %currentWindow%
SplashImage,, x0 y0 b fs12, OFF always on top.
Sleep, 1500
SplashImage, Off
}
else {
WinSet, AlwaysOnTop, on, ahk_id %currentWindow%
SplashImage,,x0 y0 b fs12, ON always on top.
Sleep, 1500
SplashImage, Off
}
return
|
|
|
|
|
I can't say I've seen any apps that force the always on top lately, with the possible exception of some splash screens on opening. I'm thinking I've seen that with a couple opening from "show hidden icons" menu on the task bar. But they don't maintain it once they load.
Some errant App code could set it or something wonky in a focus/modal call in an older program? Back in the day I used "always on top" a couple of times, but it usually turned out to be a nightmare. It's like setting the "unintended consequences" attribute
|
|
|
|
|
In a couple little utility apps I've made, I have a menu selection for this. When I do offer that option, I also offer one to make the window transparent when not top in the z-order, and a transparency percent. So even though it could be stay on top, you can still see thru it. It has it's uses.
|
|
|
|
|
I have a feeling this is not a bug in the topmost window handling in the application, but in Windows' management of which application it decides is the foreground app. There have been numerous changes to the foreground decision logic during Windows 7, 10, and 11. Some of the changes were hailed by Microsoft that they gave the user more control, and disallowed applications from the annoying tendency of grabbing the foreground. I also have the feeling some of these changes have been 'internal' in order to handle task bar notification balloons and such. There are also problems with legacy API's (for example, some message box options) that assume foreground behaviors that are no longer certain.
TL;DR - It's complicated, from some perspectives it's broke, and they ain't gonna fix it.
Software Zen: delete this;
|
|
|
|
|
This is the closest thing to a possible explanation as I've seen throughout this entire thread; seems like some people have missed my point, or intentionally ignored it.
Gary Wheeler wrote: TL;DR - It's complicated, from some perspectives it's broke, and they ain't gonna fix it.
No feature is ever so simple that MS can't find a way to complicate it to the point where it becomes buggy.
|
|
|
|
|
Windows PowerToys has a feature to toggle any app to become top-most. It would be cool for that feature to notify you which apps are already top-most, and flip that switch off if they try to force being top-most.
|
|
|
|
|
That's an intriguing idea.
If it was such a big hassle, I just might throw something together to periodically pool all windows and look which has the attribute, and log when the topmost flag gets assigned to a window - that might help narrow down what actually triggers it.
But, it's still so rare I don't think I'd invest the time in doing that. Every time I've seen this happen, closing/restarting the app is all that's needed to get the window behaving normally again, and I can certainly live with that.
|
|
|
|
|
POWER TOOLS 💪 POWER, FLEX
came to say same.
And Media Player Classic has 3 options, for all the uhm "home movies" I watch. 😶
always on top
on top while playing 👍
off
|
|
|
|
|
No, I have not seen windows forcibly moved underneath an "always on top" window, but I have often waited for some function in an app to be done with a spinning GIF indicating that it is working on the task, then several minutes later, maybe after I have given up and aborted the operation, find that there was a required dialog to continue that process underneath the main window that I was waiting on. That's one case where such dialogs should be "always on top", so I don't miss them.
|
|
|
|
|
MessageBox.Show( "blah" );
...with no parent param specified will often result in that sort of thing. If you've switched to another app before the popup appears, giving focus back to the app will NOT bring the popup back from behind whatever it's hiding.
Set your message box parents, people!!
|
|
|
|
|
I've recently started using "EPG Centre", an app that reads the EPG that's broadcast by Freeview. Its progress bar is always on top. It takes several minutes to read the EPG, so I start it and then let it run in the background, but the progress bar stays on top, for no reason.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
