WindowsCommunityToolkit icon indicating copy to clipboard operation
WindowsCommunityToolkit copied to clipboard

GridSplitter is not always fixed to cursor when moving

Open tscpp opened this issue 4 years ago • 5 comments

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

https://user-images.githubusercontent.com/47453366/115356783-49434100-a1bc-11eb-853a-a198e509a91e.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 avatar Apr 20 '21 07:04 tscpp

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 🙌

ghost avatar Apr 20 '21 07:04 ghost

Also related to #2719

michael-hawker avatar Jun 21 '21 22:06 michael-hawker

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 avatar Jun 24 '21 00:06 michael-hawker

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 avatar Mar 03 '22 00:03 michael-hawker

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 avatar Mar 03 '22 01:03 michael-hawker