Window maximize on the wrong screen when using AeroSnap

[dcm99]

Hello there,
I found your project on Youtube because I am looking for a solution with my attempt to make a borderless Window. But after I pulled the code I see that your window have the same issue than mine.
When I drag the Window to the top of the screen to maximize it with AeroSnap, the window is maximizing on the secondary screen, if more than 50% of the Window area is on the secondary screen during DragMove.
I hooked winProc Messages and listen to WM_WINDOWPOSCHANGING, and output the x and y values. But the coordinates are on the primary screen. So after WM_WINDOWPOSCHANGING something overrides the Window Position.
This behavior is pretty annoying, and if you have a monitor setup where the size and position of your monitors differs, the Title Bar of the window can be outside of the screen bounds so you have to know the shortcuts to get the window back on the screen.
After some testing, if found out that, if the Window is slightly larger than the target screen it maximize on the screen where it overlaps.
The solution for me was to decrease the Max width and height in the WmGetMinMaxInfo Method by 1.
The window maximize now on the correct Screen.

By the way: I saw that you are using the MonitorFromPoint Function to get the current screen in the WmGetMinMaxInfo Method. This only work during DragMove. When you use Window + Arrow Keys to move your Window this don’t work well. You can determ if the window is in DragMove with WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE and then use the MonitorFromWindow Function if the window isn’t moved by the mouse.

[angelsix]

I had and since fixed this bug I am sure. Are you using the latest code from master branch?

If so I will re-test on Monday

[angelsix]

Also regarding MonitorFromPoint function thats a good point thanks for the catch. I will apply that fix

[angelsix]

Fixed Win+Arrow key move if you want to verify that 272acf4

[angelsix]

I can't get a dual monitor setup until Monday to test, but can you also confirm, do normal WPF windows and Notepad on Windows act differently in the same situation? i.e. they maximize to the other window?

[dcm99]

I have your latest mater branch, just tested it on my Window 10 system, the window expand on the wrong screen. I have seen this behaviour only on WPF Windows with WindowStyle=None and AllowTransparency=True. A Window with border doesn´t do that.
The fixed "Win+Arrow Key move" works.

[angelsix]

Ok I will test monday but it sounds like you just want to change the size method to always use the MonitorFromWindow, never from mouse, then when you drag ot will be based on the window. If you test that before I can change the code to that, if not I will investigate monday.

[dcm99]

Hey do not invest much work in that if is not an issue for you. I just was looking into your code to find another aproach to handle the sizing after docking with aero snap. And it helped a lot, so thank you.

[angelsix]

Confirmed this is an issue. It is not the same behaviour as a normal window.

Repro environment

• Primary monitor on left with 200% scaling in Display Settings
• Secondary monitor on right with <200% scaling (175% for example)

Repro steps

• Change MainWindow.xaml to WindowStyle="SingleBorderWindow" and AllowsTransparency="False"
• Drag top left of window to the top right of the primary monitor, with over half the window into the second monitor and the window reduces in size due to DPI awareness, then let go to maximize.

The "maximized" ghosting appears on primary screen and it maximizes to the primary screen.

Revert back to the original WindowStyle="None" and AllowsTransparency="True" and repeat the steps. The window maximizes incorrectly to the secondary monitor.

Observational notes

We didn't change the WindowResizer, the reported max/min size of the window or any other message pumps, and just changing the window style resolved the issue.

My thoughts are it is either because of an internal bug in the .Net framework revolving around WindowStyle="None", or due to it having decoration around the window our reported min/max sizes make a difference, however I doubt that is the case.

It could also be we need to catch some other message pump details and override them.

Conclusion

For now this is a tricky one to fix. If anyone wants to look into it feel free, until then I will leave it as an open bug as it is a bug, and if I get time to dig deeper into the message pump to fix it I will