microsoft / PowerToys

Windows system utilities to maximize productivity
MIT License
110.74k stars 6.52k forks source link

[Always on Top] Unable to shift + del file as dialogue box disappears beneath windows explorer #17325

Open rp1231 opened 2 years ago

rp1231 commented 2 years ago

Microsoft PowerToys version

0.56.2

Running as admin

Area(s) with issue?

Always on Top

Steps to reproduce

Open windows explorer and navigate to the file that you want to delete. Press shift+ delete

✔️ Expected Behavior

The "Are you sure you want to delete" dialogue box should appear above the window temporarily till it is deactivated.

❌ Actual Behavior

The "Are you sure you want to delete" dialogue box appears below the window making it a hassle to reach.

Other Software

No response

franky920920 commented 2 years ago

Why do you think this is caused by Always On Top? Any clues? /needinfo

rp1231 commented 2 years ago

Hi @franky920920, This is caused by always on top as it happens only when always on top is activated. This would be expected behavior, but it causes problems in the case that I have illustrated.

Attaching videos of the same scenario with always on top enabled and disabled.

Normal behavior of dialogue box:

https://user-images.githubusercontent.com/47380919/160569743-84ff2131-faf1-499b-9560-12cab5779355.mp4

Always on top enabled behavior of the delete dialogue box:

https://user-images.githubusercontent.com/47380919/160569986-e08c605e-7a47-442c-b98a-89a39b37101c.mp4

When pressing shift+del, the delete dialogue box gets hidden behind the window. This makes sense considering the window is supposed to stay on top. But maybe Always on top can exclude important dialogue boxes like these if they originate from the window marked as always on top.

SeraphimaZykova commented 2 years ago

For now, it's expected behavior, AlwaysOnTop tracks only windows that are pinned on top. We can mark this issue as an enhancement and probably plan it for future releases.

rp1231 commented 2 years ago

That would be great!

rp1231 commented 2 years ago

@SeraphimaZykova I have identified that the class of the delete dialog box is : #32770 | The class for a dialog box From https://docs.microsoft.com/en-us/windows/win32/winmsg/about-window-classes#:~:text=%2332770,a%20dialog%20box.

If this class of window can be made permanently on top, Maybe this can be solved?

SeraphimaZykova commented 2 years ago

If this class of window can be made permanently on top, Maybe this can be solved?

Thank you for your investigation! Unfortunately, this won't work. There's no way to change other window's class, especially for the other app.

rp1231 commented 2 years ago

If this class of window can be made permanently on top, Maybe this can be solved?

Thank you for your investigation! Unfortunately, this won't work. There's no way to change other window's class, especially for the other app.

I think you misunderstood me. I'm not asking for the window class to be changed.

I'm saying that if that window class can be marked as on top on creation. for eg. I'm currently using this autohotkey script to solve this problem.

#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.
}

It watches for the creation of the #32770 class window and automatically marks it as on top. And the first time it is defocused, it loses the alwaysontop property. This allows it to appear on top of the other alwaysontop windows temporarily.

I'm more of a power user than a programmer, So I'm not sure how this could be implemented in the app.

SeraphimaZykova commented 2 years ago

It watches for the creation of the #32770 class window and automatically marks it as on top.

Got it, thank you. We've already discussed with a team possibility of busy-waiting as you described, and it can be implemented. But in general, it could lead to inconvenience for most of the users due to CPU workload. That's the main concern.

rp1231 commented 2 years ago

Ah, I see. Thanks for the explanation.

Maybe it could be an opt in method? Maybe a text field allowing you to white list windows that could be "on-topped" on creation? I'm pretty sure you guys must have discussed these things. Mentioning these points just in case......

rp1231 commented 2 years ago

I have identified one more window that would fit into the same category "OperationStatusWindow" Posting this here incase this feature is worked upon.