Feature: Improved behavior when dragging items from an unfocused Files window

[Jack251970]

Resolved / Related Issues

• Added support for not focusing Files window when dragging a file/folder
• Closes Feature: Don't focus Files window when dragging a file/folder #13255

Steps used to test these changes

Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.

1. Opened Files and File Explorer.
2. Select files in Files.
3. Move File Explorer on the top, which is topper than Files. Make sure it doesn't cover Files so that you can drag files from Files.
4. Drag the selected files to the File Explorer. And you can find the Files won't move to the top when dragging files.

[yaira2]

@Jack251970 the behavior is working nicely when Files is maximized. Is there a way to also do this when Files isn't maximized?

[Jack251970]

@yaira2 Sorry, I cannot get your meaning. What is the difference between the behaviour when File is maximized and when it is not?

[Jack251970]

https://github.com/user-attachments/assets/91b17452-b706-47fe-be16-89460ec12508
I think the behaviour like this is enough compared to system File Explorer?

[yaira2]

@yaira2 Sorry, I cannot get your meaning. What is the difference between the behaviour when File is maximized and when it is not?

I meant that Files is brought to the foreground if the window isn't maximized.

[Jack251970]

@yaira2 Sorry, I cannot get your meaning. What is the difference between the behaviour when File is maximized and when it is not?

I meant that Files is brought to the foreground if the window isn't maximized.

Sorry, still no idea about why Files needs to be brought to the foreground if the window isn't maximized. (Under what situation?)

As you can see in the video above, my codes implement a function that the Files will stay in the current z index (not be brought to front for covering another topper window that need to drag files into) if dragging selected files so that it will have the same experience as system File Explorer.

[0x5bfa]

Putting aside the behavior, you can use DidPositionChanged from AppWindow.Changed event instead of utilizing win32 apis.

[Jack251970]

Putting aside the behavior, you can use DidPositionChanged from AppWindow.Changed event instead of utilizing win32 apis.

I am not quite familiar with this api. Will it make some differences?

[yaira2]

@Jack251970 I'm referring to the behavior (around two seconds into your recording) where the Files window is brought to the foreground.

1. Open Files regularly (not maximized)
2. Select a file
3. Switch the focus to File Explorer
4. Start dragging the selected file from Files
5. Files is brought to the foreground

Isn't the expected behavior for File Explorer to remain the topmost window?

[Jack251970]

@Jack251970 I'm referring to the behavior (around two seconds into your recording) where the Files window is brought to the foreground.

1. Open Files regularly (not maximized)
2. Select a file
3. Switch the focus to File Explorer
4. Start dragging the selected file from Files
5. Files is brought to the foreground

Isn't the expected behavior for File Explorer to remain the topmost window?

Get it. I will try to make this work.

[yaira2]

Thanks! I should note, your current changes already helped to resolve this issue when the window is maximized.

[0x5bfa]

Will it make some differences?

Yeah you don't have to hook/unhook win32 window message loop, there's high-level API wrapper called WinRT API as opposed to low-level Win32 API.

This API let you just subscribe an event. Go to MainWindow and subscribe this.AppWindow.Changed event and get args.DidPositionChange property value.

[Jack251970]

Will it make some differences?

Yeah you don't have to hook/unhook win32 window message loop, there's high-level API wrapper called WinRT API as opposed to low-level Win32 API.

This API let you just subscribe an event. Go to MainWindow and subscribe this.Changed event and get e.DidPositionChanged property value.

Sure, I will have a try.

[Jack251970]

@yaira2 Sorry about the misunderstanding description (I have removed the useless step that asks you to maximize the Files window). This feature can work while Files isn't a maximized window.
In my recording around 2 seconds, the reason why Files is brought to the front is that I have selected a new item (09-20-37.mp4) instead of the original one (09-28-05.mp4). This behaviour is just like the system File Explorer.

[Jack251970]

@0x5bfa Yeah I have found that AppWindow.Changed event contains information about DidPositionChange & ZOrderChange, but I cannot handle these changes. (AppWindowChangedEventArgs does not have Handle property, and I cannot stop those changing event)

So I think WindowMessageReceived event in WinUIEx.WindowManager is the only way to implement this and WinUIEx package has provided a good solution for this.

[yaira2]

@Jack251970 thank you for clarifying. I'll test again to confirm the behavior works on my side.

[0x5bfa]

Yeah I have found that AppWindow.Changed event contains information about DidPositionChange & ZOrderChange, but I cannot handle these changes. (AppWindowChangedEventArgs does not have Handle property, and I cannot stop those changing event)

Thanks, I missed that. I'll file a feature request on WinAppSdk for this later.

[yaira2]

@Jack251970 I can confirm the behavior is working as expected. I'm going to wait for a review from @hishitetsu, but as far as I'm concerned I have no requested changes.