Fix double-click maximize issue referenced by #43 #45
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 windowTitleBar
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 theMouseMove
event for theRootGrid
element.This PR fixes the issue with the following logic:
GetCursorPos
)MouseMove
event, after appropriate logic passes (e.g. left button is down and parent window is not null)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 byGetCursorPos
.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 intoRootGrid.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.