feat: expose TreeViewItem expansion status to root event. #16984
Conversation
|
You can test this PR using the following package version. |
src/Avalonia.Controls/TreeView.cs
Outdated
| /// <summary> | ||
| /// Represents the event that is raised when the expansion state of a <see cref="TreeViewItem"/> changes within a <see cref="TreeView"/>. | ||
| /// </summary> | ||
| public event EventHandler<TreeViewItemExpansionChangedEventArgs> ExpansionChanged |
There was a problem hiding this comment.
For Expander, we use ExpandedEvent/ExpandingEvent and CollapsedEvent/CollapsingEvent. It would be expected to have at least ExpandedEvent and CollapsedEvent here for consistency, but not ExpansionChanged.
There was a problem hiding this comment.
Yes, let's skip ExpandingEvent and CollapsingEvent events for now, as these are cancellable and more tricky to implement.
ExpandedEvent and CollapsedEvent should be enough for most apps.
|
You can test this PR using the following package version. |
src/Avalonia.Controls/TreeView.cs
Outdated
| /// <summary> | ||
| /// Defines the <see cref="Expanded"/> event. | ||
| /// </summary> | ||
| public static readonly RoutedEvent<RoutedEventArgs> ExpandedEvent = | ||
| RoutedEvent.Register<TreeView, RoutedEventArgs>(nameof(Expanded), RoutingStrategies.Bubble); | ||
|
|
||
| /// <summary> | ||
| /// Defines the <see cref="Collapsed"/> event. | ||
| /// </summary> | ||
| public static readonly RoutedEvent<RoutedEventArgs> CollapsedEvent = | ||
| RoutedEvent.Register<TreeView, RoutedEventArgs>(nameof(Collapsed), RoutingStrategies.Bubble); |
There was a problem hiding this comment.
Sorry, I haven't noticed at first, but why does TreeView has these events? And not TreeViewItem? Makes more sense to be on the item.
It's still possible to handle these events on the TreeView or any other higher-position control, since this event bubbles:
treeView.AddHandler(TreeViewItem.CollapsedEvent, Handler);Also with 11.2, it's possible to subscribe to any routed event:
<TreeView TreeViewItem.CollapsedEvent="Handler" ItemsSource="{Binding Source}" />There was a problem hiding this comment.
I made the design from user prototype (directly add class handler in TreeView level in xaml) but yes, with the new RoutedEvent update we can add with your second sample. Can I assume this PR will not be backported to 11.1?
There was a problem hiding this comment.
Most likely, yes, it will go into 11.2, if merged this week.
| /// </summary> | ||
| public class TreeViewItemExpansionChangedEventArgs: RoutedEventArgs | ||
| { | ||
| public TreeViewItem Source { get; } |
There was a problem hiding this comment.
This property can be removed for consistency and not conflict with object RoutedEventArgs.Source
There was a problem hiding this comment.
Actually, with events separation, this custom event args are less useful now.
There was a problem hiding this comment.
hmm i forgot to delete it.Thanks.
…ix documentation. 4. Change routing to Bubble|Tunnel as both parent and children may care about this epxanding status.
|
You can test this PR using the following package version. |
What does the pull request do?
Expose TreeViewItem expansion change status to a RoutedEvent in root TreeView. Thus developer can easily track the change.
What is the current behavior?
No such a convenient way.
What is the updated/expected behavior with this PR?
How was the solution implemented (if it's not obvious)?
Since TreeView instance is already available in TreeViewItem, just manually raise a new defined event.
Checklist
Breaking changes
Obsoletions / Deprecations
Fixed issues