[GridSplitter] Fix #339: resize both items when they are fixed size to avoid the change overflowing to the irrelevant Star-sized item

[abdes]

Fixes

Fixes #339

Please see #339 for a detailed description of the problem with video of the interaction.

• Formatted the GridSplitter experiment XAML code with XAMLStyler to avoid unnecessary diffs in the history. Please note that this is theoretically unnecessary, but it should be done anyway given that the project requires XAMLStyler style to be enforced.
• Augmented the GridSplitter sample to add one more column and set the last 2 columns to fixed size to demonstrate the issue before the fix and the resolution after the fix.
• Fixed the issue by making the GridSplitter resize both current and sibling when they are both fixed size.
• Verified that the new behavior honors the minimum size constraint.

PR Type

What kind of change does this PR introduce?

Bugfix
Code style update (formatting)

Sample app changes

What is the current behavior?

Please see #339 for a detailed description of the problem with video of the interaction.

What is the new behavior?

GridSplitter.339.fixed.mp4

PR Checklist

Please check if your PR fulfills the following requirements:

• Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
• Based off latest main branch of toolkit
• Tested code with current supported SDKs
• New component
  • Documentation has been added
  • Sample in sample app has been added
  • Analyzers are passing for documentation and samples
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• Tests for the changes have been added (if applicable)
• Header has been added to all new source files
• Contains NO breaking changes

Other information

[abdes]

@dotnet-policy-service agree

[michael-hawker]

@abdes it appears you applied different XAML Styler settings than the for the file we have in the repo, ensure your plugin is configured to look upwards in the folder structure for settings files.

I also don't think this behavior is correct. If the limit has been reached for the size a column should grow, no more movement should occur. Here we see the 1 & 2 columns being affected by the changes to the 3 & 4 now, i.e. the third column growing more as you continue to drag to the right and pushing the other two out of the way.

Once the 4th column is the smallest, it should no longer update anything else.

There is ambiguity in if the last column should be able to go beyond the size of the grid. I believe in WPF, it would extend the size of the grid itself to grow beyond the original bounds.

[abdes]

Got it.

• Reverted the changes on styling. Just used the PowerShell script. Could not find how to make the VS Extension auto-find the XAMLStyler config.

• For the resizing, now it checks the constraints (for both the current and the sibling) before allowing the resize to proceed. Previously, the check was only done for the row/column being changed. In fact it should be done for both because if any of the two impacted rows/columns cannot be resized then the other one should not be resized as well.

GridSplitter.339.fixed.mp4

@michael-hawker please check the new implementation

[abdes]

Can we get a reviewer to move this forward please?
I've attached videos, met all requirements and am ready to make any additional modifications needed.

[abdes]

@Arlodotexe
Please approve the workflow...

[Arlodotexe]

Tested locally under Uwp, Wasdk and Wasm. Code looks good and it does fix the issue. Let's get this merged! 🎉