Skip to content
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

Fix double-click maximize issue referenced by #43 #45

Merged
merged 1 commit into from
Jan 27, 2022
Merged

Fix double-click maximize issue referenced by #43 #45

merged 1 commit into from
Jan 27, 2022

Conversation

Aelarion
Copy link
Contributor

@Aelarion Aelarion commented Jan 26, 2022

This PR fixes the bug where double clicking a TitleBar was not maximizing the window (fix #43).

The issue was caused by the RootGrid.MouseMove being triggered from the double-click maximize functionality (to reproduce, the window TitleBar needed be at the top of the screen such that the mouse was over it when the window is maximized by the double click event). It appears that since the window dimensions change when the state changes, this affects the mouse coordinates and thus fires the MouseMove event for the RootGrid element.

This PR fixes the issue with the following logic:

  • Cursor position is tracked in a private field when the double-click maximize fires (via Win32 GetCursorPos)
  • The cursor position is compared in the MouseMove event, after appropriate logic passes (e.g. left button is down and parent window is not null)
  • If their X and Y are equal (meaning the mouse has not moved) the method simply returns and does nothing

This workaround doesn't necessarily feel "great" (e.g. resorting to Win32 calls for the cursor position) -- however this is necessary due to how the mouse coordinates are calculated in WPF (e.g. via visual to screen coordinates). I was still able to reproduce this issue when using PointToScreen calculations (albeit less frequently). For this fix, we want to track the absolute coordinates of the cursor independent of the application and this is primary functionality provided by GetCursorPos.

NOTE: This fix was tested with 125% and 150% DPI scaling, however it really should not have any dependence on DPI scaling. Since the coordinates are being compared in absolutes on whatever scale is provided by Win32, as long as that scale doesn't change between comparisons (essentially immediately), then the scaling is not needed.

EDIT: The consolidation of the RootGrid.MouseDown handler into RootGrid.MouseMove (mentioned in this comment) has been implemented in this PR as well. It was not necessarily causing the particular issue but should be deconflicted nonetheless.

@pomianowski pomianowski merged commit d563784 into lepoco:main Jan 27, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Double-click sometimes incorrectly maximizes the application
2 participants