Fix SelectionChanged not raised on collection Reset#20942
Fix SelectionChanged not raised on collection Reset#20942NathanDrake2406 wants to merge 4 commits intoAvaloniaUI:masterfrom
Conversation
|
You can test this PR using the following package version. |
|
@NathanDrake2406 Is there something missing that you converted this PR to a draft? |
|
You can test this PR using the following package version. |
ecab00d to
f2e8388
Compare
…deselected When a collection bound to a SelectingItemsControl (e.g. ListBox) was cleared via NotifyCollectionChangedAction.Reset, the SelectionChanged event was not raised despite the selection being lost. The root cause was in InternalSelectionModel.OnSourceReset: the base SelectionModel.OnSourceReset() directly reset _selectedIndex to -1 before any Operation could capture the old selection state. The subsequent SyncFromSelectedItems created an Operation that saw no change (old and new both -1), so CommitOperation never fired SelectionChanged. The fix snapshots _writableSelectedItems before sync, diffs against the post-sync state to find items that were actually lost (not merely re-selected at a new index after reorder), and injects them as DeselectedItems on the pending Operation — following the same pattern used by OnSelectionRemoved for individual item removals. Fixes AvaloniaUI#20897
68eb1d7 to
7db50f8
Compare
|
You can test this PR using the following package version. |
|
I had a deeper look at this. From my understanding, the current behavior is expected from the However, the An alternative would be to add a flag or operation type to cc @grokys for additional thoughts. |
The Reset diff in InternalSelectionModel used a HashSet to detect which previously-selected items were still present after sync. Selection allows duplicates (same instance or equal items at multiple indices), so set semantics collapsed duplicates into one entry and under-reported deselections when only some occurrences were lost. Track counts per item plus a null counter and decrement per match, so RemovedItems reflects the actual number of lost selections. Adds a duplicate-items Reset test covering the regression.
ListBox and other SelectingItemsControl callers did not receive SelectionChanged when a Reset cleared the selected items. The selection model reports this path through LostSelection, but the control only used that callback for AlwaysSelected recovery. Track the last selected items at the control boundary, capture that snapshot for Reset notifications, and raise the routed SelectionChanged event when LostSelection commits during that reset. This avoids diffing reset contents while preserving the removed-items payload for clear/reset-to-empty cases.
|
You can test this PR using the following package version. |
What does the pull request do?
Fixes
SelectingItemsControl.SelectionChangednot being raised when an items collection sends aResetnotification that clears the current selection. This covers controls such asListBoxbound to anObservableCollectionthat is cleared.What is the current behavior?
When a selected item is removed by a
Reset,SelectionModelreports the loss throughLostSelection.SelectingItemsControlonly uses that callback to recoverAlwaysSelectedselection, so no public routedSelectionChangedevent is raised for reset-to-empty cases.What is the updated/expected behavior with this PR?
SelectionChangedis raised when a reset causes the control to lose its selected items. The event reports the previously selected items inRemovedItemsand does not report removals when a reset preserves the selection.Validated with:
dotnet run --project tests/Avalonia.Controls.UnitTests/Avalonia.Controls.UnitTests.csproj -- --filter-class "Avalonia.Controls.UnitTests.Primitives.SelectingItemsControlTests"dotnet run --project tests/Avalonia.Controls.UnitTests/Avalonia.Controls.UnitTests.csproj -- --filter-class "Avalonia.Controls.UnitTests.Selection.InternalSelectionModelTests"dotnet run --project tests/Avalonia.Controls.UnitTests/Avalonia.Controls.UnitTests.csproj -- --filter-namespace "Avalonia.Controls.UnitTests.Selection"How was the solution implemented (if it's not obvious)?
SelectingItemsControlnow keeps a snapshot of the last selected items at the control boundary. When an itemsResetstarts, the control captures that existing snapshot. IfSelectionModel.LostSelectionis committed for that reset, the control raises the routedSelectionChangedevent using the captured items asRemovedItems.This keeps
SelectionModelreset semantics intact and avoids diffing the reset collection contents.Checklist
Breaking changes
None.
Obsoletions / Deprecations
None.
Fixed issues
Fixes #20897