Some dialogs appear below "always on top" windows

[rp1231]

trafficstars

Allow child windows to be above always on top windows. For eg. When you have an explorer window always on top and you try to shift+delete a folder. The dialog box for "Are you sure you want to permanently delete the folder" should show up on top of the "always on top" window.

Is something like this possible?

[RamonUnch]

If the windows is no longer visible, then it means it is not a child window. If the window is created as a child window or if the window is owned, then the OS will ensure that the child/decedents are always above the ancestor.

It looks like a bug from explorer, on Windows 7/XP the bug was not present. Could you identify with AltSnap this window?

[RamonUnch]

For an example of a working program, have a look at notepad.

[rp1231]

This is the explorer window:

This is the Delete file dialog:

Also one more example is: I use a 3rd party tool called quicklook which enables a mac style preview window on pressing the space key. And if the window is always on top, the preview window is generated below the window. So maybe not necessarily child windows, but windows that originate from the always on top window. (If detecting something like that is even possible) Or in this specific case I would like to have the quick look window always be on top. (So maybe some kind of always on top exclusion list?)

[RamonUnch]

I do not see how I could do that, AltSnap is not informed when a new window is created or when you open/preview a file. The always on top setting is just a window flag that can be set on or off, once a window is set topmost AltSnap stops doing anything and the OS is handling the topmost flag himself.

I agree this is a valid concern but trying to hook system function to auto-detect for each new window if it is not potentially a child window is not in the scope of AltSnap. I would suggest you try to convince the developers of pinwin which is focused on topmost exclusively, or maybe something else.

I am not sure how quicklook works but maybe they can fix it.

[rp1231]

Yep this isn't the most straightforward problem.... The quicklook thing was just another example apart from the delete folder dialog.

[RamonUnch]

I will keep this issue visible in the README FIRST issue.

[rp1231]

The quicklook issue was solved. I just had to select a stay on top toggle and now it works fine. As for the delete dialog, maybe windows just changed the way it does things.

[rp1231]

Were you able to make out something from the screenshots of the window details I posted? Is the delete folder window different from the one created in windows 7/XP/10?

[RamonUnch]

It looks the same but I am missing an information. I will make a modified AltSnap so that it displays it.

[RamonUnch]

AltSnap_owner_parent_x64.zip On there are two kind or relationship between window, a window can own an other window and/or have child windows. So there are several kind of windows:

1. Toplevel windows that are not owned and have no parents
2. Child windows that have a parent.
3. Owned window (that have an owner).
4. ~~owned child windows (both 2 + 3). Tis is the case on windows 7 of delete confirmation.~~

EDIT: Actually you cannot have both a parent and an owner.

So this AltSnap version will display the hanldes of corresponding parent and owner in the identify window option.

[rp1231]

This is the explorer window: This is the delete dialog:

Seem like there is no parent child relationship anymore.

[RamonUnch]

This is what I expected unfortunately. If you try Notepad's dialog, I am almost sure you will have both. Just a question, are you able to move the explorer window in front of its confirmation dialog without AltSnap?

[rp1231]

I'm not sure what you mean by without AltSnap... This happens when the alwaysontop option in altsnap is active. Do you mean without the titlebar move action?

[RamonUnch]

No I just mean, Shift+Del a file, let the confirmation dialog opened and click on the explorer window from which you did Shift+Del. Does the confirmation dialog stays on top?

[rp1231]

I've uploaded a video. Hope it clears it up. Let me know if it's not.

https://user-images.githubusercontent.com/47380919/182878568-bc02eb53-a3aa-4fb3-abcd-68aa7a1bead4.mp4

[RamonUnch]

My question is : Can you try to hide the confirmation dialog behind the explorer window without applying the always on top flag.

Thanks a lot for your efforts, I feel obliged when you take time and effort to make a video.

[RamonUnch]

The idea is that if the system finds a way to force the dialog on top of explorer's window outside of AltSnap's interaction, then there is the potential to fix at least this bug. If you are able to move both windows in front of one another like with two explorer windows then I do not see how this bug could be fixed because it would mean that the explorer really does not tell anyone that it is his dialog box.

[rp1231]

Ah ok I understood now. Yes, I can hide the confirmation dialog behind the explorer window without applying the always on top flag.

[rp1231]

So that means that the issue will have to be brought up with microsoft.

[RamonUnch]

I would indeed consider this as a windows bug, because it can become very easy to loose this dialog like this. This could also be seen as a feature because, someone might want to keep working on the folder while having the dialog opened and would otherwise be disturbed by the dialog.

[rp1231]

This is the explorer window: This is the delete dialog:

Seem like there is no parent child relationship anymore.

Would it be possible to add a whitelist for adding always on top to some windows. For eg. the delete dialog which is *|#32770 So that it is always created with always on top enabled? That would solve the problem of these windows I think.

[RamonUnch]

This is not possible because AltSnap cannot modify windows on the fly when they are popping up. AltSnap only interacts with the windows you select and when you perform an action.

Keep this issue opened, so that people can see and comment on it more easily.

[rp1231]

If anyone wants to solve this issue and doesn't mind running autohotkey in the background, I have written an autohotkey script to solve the issue of the delete dialog not showing up on top. And any other window with the ahk_class #32770 It disables the ontop on the dialog after it loses focus once. You might have to modify this to suit your needs.

#SingleInstance force
Loop
{
	IfWinActive ahk_class #32770
	{
		WinSet, AlwaysOnTop, on
		WinWaitNotActive ahk_class #32770
	    WinSet, AlwaysOnTop, off
	}
	
	Sleep 100  	; This adds a 100ms delay.  Adjust as desired. Smaller values can hog the CPU, higher values can take longer to notice the active window.
}

This can be done better with the set timer method, but this works just fine.

[rp1231]

@RamonUnch Is there any method of detecting modeless dialog boxes?

[RamonUnch]

Well any window that has no parent and no owner could be considered as modeless.

You can use GetParent() function to know if a window has a parent. If it has no parent then it will return the owner window and if it has no parent and is not owned then it will return NULL. In case GetParent return NULL, it means there is no defined relationship of any kind between this window and an other one.

To determine is a window is a small popup dialog box, similar to the delete confirmation, there is no reliable way. You could however check if the dialog does not appear in the taskbar ie: it has the WS_EX_TOOLWINDOW extended flag and/or no minimize/maximize/system menu buttons in its caption. Probably there is more this is just what comes from the top of my head.

[rp1231]

Thanks