-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
GridSplitter is not always fixed to cursor when moving #3949
Comments
Hello tscpp, thank you for opening an issue with us! I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌 |
Also related to #2719 |
I did a quick comparison with how WPF behaves (as our control is supposed to be API compatible for the most part with it). What WPF does is when the cursor moves back in the opposite direction after having passed a bound, it doesn't start moving the gripper bar again until the cursor has caught back up to it. So while it doesn't break the boundaries (as expected), it is still always 'snapped' to the bar when the bar is moving. It was a bit hard to tell how this is achieved, our implementation is much different that the WPF one. I wonder if it makes sense to re-align as part of #2976. Basically any area of drag past the restricted bounds setup by the Grid act as 'dead-zones' where no movement of the splitter occurs when the mouse moves (until it is back over the bar in the acceptable bounded region for resizing). |
I'm working on a fix finally for this as part of our refactor! Realized the manipulation events in UWP provide the Cumulative values as well which should make this fairly straight-forward. I have it working on our new |
…er all use Cumulative change to update sizes vs. Delta This fixes long-standing issue where mouse would de-sync from gripper bar and provide a disorienting experience to users. Now the bar only moves when the mouse is over it and ignores extra movement - the same as Thumb controls do within a Slider for instance.
I've also confirmed that this behavior was shipped back in the original 1.1 version of the Toolkit code, as far as I can tell. It was in its current form as of 2.0 in the Manipulation events. But both used So this'll probably go down as longest outstanding bug to be fixed in the Toolkit for a while... 😋 |
…er all use Cumulative change to update sizes vs. Delta This fixes long-standing issue where mouse would de-sync from gripper bar and provide a disorienting experience to users. Now the bar only moves when the mouse is over it and ignores extra movement - the same as Thumb controls do within a Slider for instance.
…er all use Cumulative change to update sizes vs. Delta This fixes long-standing issue where mouse would de-sync from gripper bar and provide a disorienting experience to users. Now the bar only moves when the mouse is over it and ignores extra movement - the same as Thumb controls do within a Slider for instance.
Describe the bug
If the correct behavior of the grid-splitter is to not always follow mouse as shown in the video, please close this issue. I recently created a question (https://stackoverflow.com/q/67162622) about the behavior. Only the mouse movement affects the grid-splitter, the mouse/cursor is not always on the grid-splitter when it moves.
Steps to Reproduce
Steps to reproduce the behavior:
Expected behavior
The grid-splitter should only move when the mouse/cursor is on it. The position of the grid-splitter should be determined by the mouse/cursor position and not movement.
Screenshots
Reproduce.2021-04-20.09-38-53.mp4
Environment
The text was updated successfully, but these errors were encountered: