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

GridSplitter is not always fixed to cursor when moving #3949

Open
2 tasks
tscpp opened this issue Apr 20, 2021 · 5 comments
Open
2 tasks

GridSplitter is not always fixed to cursor when moving #3949

tscpp opened this issue Apr 20, 2021 · 5 comments
Assignees
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior controls 🎛️
Milestone

Comments

@tscpp
Copy link

tscpp commented Apr 20, 2021

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.

  • Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

  • Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

  1. Run Windows 10 20H2 (OS Build 19042.928)
  2. Create a new "Blank App (Universal Windows)" project in Visual Studio 2019
  3. Select "Target version" to "Windows 10, version 2004 (10.0; 19041)" and "Minimum version" to "Windows 10, version 1809 (10.0; 17763)".
  4. Click on the soulution > Manage NuGet Packages... > Browse, select version 7.0.1 and click Install
  5. Set App.xaml to:
    <Application
        x:Class="Reproduce.App"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    >
    
        <Application.Resources>
    	    <XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" />
        </Application.Resources>
    
    </Application>
  6. Set MainPage.xaml to:
        <Page
            x:Class="Reproduce.MainPage"
            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
            xmlns:local="using:Reproduce"
            xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
            xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    	    xmlns:controls="using:Microsoft.Toolkit.Uwp.UI.Controls"
            mc:Ignorable="d"
            Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    
    	<Grid>
    
    		<Grid.RowDefinitions>
    			<RowDefinition Height="39"></RowDefinition>
    			<RowDefinition></RowDefinition>
    		</Grid.RowDefinitions>
    
    		<Grid.ColumnDefinitions>
    			<ColumnDefinition MinWidth="100"></ColumnDefinition>
    			<ColumnDefinition Width="2"></ColumnDefinition>
    			<ColumnDefinition></ColumnDefinition>
    		</Grid.ColumnDefinitions>
    
    		<controls:GridSplitter
                    Grid.Column="1"
                    Grid.Row="0"
                    Grid.RowSpan="2"
                    Width="2"
                    ResizeBehavior="BasedOnAlignment"
                    ResizeDirection="Auto"
                ></controls:GridSplitter>
    
    	</Grid>
    </Page>

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

NuGet Package(s): 
Microsoft.NETCore.UniversalWindowsPlatform: 6.2.11
Microsoft.Toolkit.Uwp.UI.Controls: 7.0.1

Package Version(s): 
I don't know what this refers to...

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [x] May 2020 Update (19041)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [x] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (xxxxx)

Device form factor:
- [x] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ ] 2019 (version: ) 
- [x] 2019 Preview (version: 16.9.4)

@tscpp tscpp added the bug 🐛 An unexpected issue that highlights incorrect behavior label Apr 20, 2021
@ghost ghost added the needs triage 🔍 label Apr 20, 2021
@ghost
Copy link

ghost commented Apr 20, 2021

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 🙌

@michael-hawker
Copy link
Member

Also related to #2719

@michael-hawker
Copy link
Member

michael-hawker commented Jun 24, 2021

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).

@michael-hawker
Copy link
Member

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 ContentSizer control with the new base class we're creating. I just need to update the GridSplitter code to utilize it as well... doing that on my dev stream at this very moment... 🦙 https://twitch.tv/XAMLLlama

michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Mar 3, 2022
…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.
@michael-hawker
Copy link
Member

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 Delta offsets to update as things dragged vs. the new Cumulative method.

So this'll probably go down as longest outstanding bug to be fixed in the Toolkit for a while... 😋

michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Mar 5, 2022
…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.
michael-hawker added a commit to michael-hawker/UWPCommunityToolkit that referenced this issue Mar 7, 2022
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior controls 🎛️
Projects
None yet
Development

No branches or pull requests

2 participants