-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Win32 - Fix Window Frame Size and Position issues. #16608
Conversation
a8753ef
to
3f1053f
Compare
You can test this PR using the following package version. |
You can test this PR using the following package version. |
You can test this PR using the following package version. |
|
||
SetWindowPos(_hwnd, IntPtr.Zero, newRect.left, newRect.top, newRect.Width, newRect.Height, | ||
SetWindowPosFlags.SWP_NOZORDER | SetWindowPosFlags.SWP_NOACTIVATE | | ||
SetWindowPos(_hwnd, IntPtr.Zero, rcWindow.left, rcWindow.top, 0 ,0, |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
You can test this PR using the following package version. |
Also, do we need this another PR from @TomEdwardsEnscape ? |
It seems their pr only extends client when a show operation is done, and not when window state is changed. Just to be certain extendclient is always checked, we can have both changes in. |
e1f801c
to
f76dada
Compare
f76dada
to
0211900
Compare
You can test this PR using the following package version. |
0211900
to
a847b8f
Compare
You can test this PR using the following package version. |
Would this solve #11333? |
@josephmoresena it should. You can check that by using nighly build from #16608 (comment) |
FYI this change introduced multiple issues with my |
What does the pull request do?
Our Window properties that rely on the window border/frame have inconsistent behavior on windows, esp. when compared to WPF. This pr ensures that the FrameSize and window Position doesn't change when decorations are changed, and client area is affected. Window Position and FrameSize now considers the whole window border, including the transparent border Windows apply to resizable windows. The following rules are enforced;
First time window without borders has incorrect position #16529
11.1.0 - Window position is incorrect when the SystemDecorations property is set to BorderOnly #16454
Caption Buttons disappearing #16503
What is the current behavior?
Window Position doesn't consider the transparent part of the border, only the visible part, which is usually just 1 pixel wide. This causes the window Position to change when client is extended to window frame, even though the window hasn't moved. This behavior also affects reported FrameSize, even though the window hasn't been resized.
For normal windows with system decorations, setting system decorations to BorderOnly or None forces Frame to shrink to client area, instead of growing the client area like it is in WPF.
What is the updated/expected behavior with this PR?
Window FrameSize and Position are only updated when there's a change in WindowState, when user updates Window.Position or when use resizes the window. They are kept unchanged when there's an update to ExtendedClient properties and SystemDecorations. FrameSize and Position will consider all parts of the window that the OS considers as part of the window decorations.
How was the solution implemented (if it's not obvious)?
Checklist
Breaking changes
Obsoletions / Deprecations
Fixed issues
Fixes #16529
Fixes #16454
Fixes #16503
Fixes #14604
Fixes #11411