Feature Request (or bug?): Show child windows above windows set to always-on-top

[vertigo220]

If I set a window to AOT and it spawns a child window, that window should generally be shown over the parent window despite it being set to AOT, as it's understood that a) that window belongs to the window with that setting and so should inherit the AOT property, and b) it needs to be visible to interact with it (not to mention to see that it opened in cased it's smaller than and directly behind the parent window). While it does seem to sometimes do this, it doesn't always. As an example, with MKVToolNix, the warning message when clicking the "Start multiplexing" button when a file with the same name as that set in the "Destination file" box already exists asking if you want to overwrite the file does show over the main window. But if modifying the language of a track, the language selection window opens behind the main window.

[gileli121]

@vertigo220
Thanks for the feedback.
I don't have enough time right now to delve into this, but it sounds like it could be interpreted as something that isn't considered a bug. I'm hesitant to interfere with the behavior in such a case. Others might consider the behavior to be correct. Could you elaborate further on why you think it's a bug?

[vertigo220]

Two reasons. First, because, as I explained, the expected, and desired, behavior (for me at least, and I assume for most others) would be that child windows would not be hidden behind a window just because that window is set to AOT, i.e. the AOT state applies to a window's z-order in relation to other apps, not itself). Second, because at least some child windows are still shown on top, as is the expected/desired behavior, so the fact others aren't seems more like a bug in that it's random and seems inadvertent.

[gileli121]

I see.
However, this behavior should be handled by the OS itself.
In Windows, if a window has a parent window, the OS ensures that the child window remains above the parent window (even without WindowTop). If this is not happening, it likely means the app is not creating windows properly.

That said, it could still be a question of whether WindowTop should address this issue, but the expectation is that the app should be written correctly and handle windows appropriately.

[vertigo220]

If it's the program, though, then why does the window show on top as it should when the main window isn't set on top, and is only behind it when it is set to be on top?

Obviously, you know more about the mechanics of z-ordering and focus than I do, so if you insist I'll take your word for it, but I'm not convinced this is an issue with MKVToolNix and not with WindowTop. In any case, assuming it doesn't require a significant amount of work, I'd think it would be best for this program to monitor that sort of thing and handle any issues. After all, even though it should be up to individual programs to control those things, they don't always do so correctly and, perhaps more importantly, the whole purpose of this program is to interfere with that, manipulating things to do what the user wants, so handing issues where programs don't properly configure their windows' z-orders seems, to me, to fall in its purview. And that includes Windows itself, by the way, which I've found to be horrible at this since Win 10, as windows behind other windows are constantly not being brought to the top when clicking on them, requiring me to click another window then back to the one I want to get it to come to the front. This happens on pretty much a daily basis and has as long as I can remember since "upgrading" from 7.

[vertigo220]

Subtitle Edit does this as well. For example, set the main window on top then go to File > Compare... or Options > Settings... (other child windows of this program do it, too, in fact, AFAICT, all of them do, these are just easy ones to test).