Browse Source
* fix: raise SelectionChanged event on collection Reset when items are 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 #20897 * fix: use multiset diff to report lost duplicate selections on Reset 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. * fix: raise SelectionChanged for reset-lost selection 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. * fix: address review feedback on SelectionChanged Reset snapshot - Replace per-change ToArray() snapshot with persistent List<object?> to avoid allocations on every selection change (review: MrJul). - Read snapshot in PreCollectionChanged instead of Selection.SelectedItems because the source is already empty by the time Reset fires. - Align LostSelection event-raising with SelectionChanged path: use BuildEventRoute + HasHandlers guard to avoid allocating args when no handlers are attached (review: copilot). - Harden existing Reset tests to Assert.Single to catch double-fire. * fix: consolidate SelectionChanged raising and defend against stale snapshot - Extract RaiseSelectionChanged helper so both the normal (SelectionChanged) and reset (LostSelection) paths share the same BuildEventRoute/HasHandlers guard and SelectionChangedEventArgs construction (review: copilot). - Move _selectedItemsBeforeReset clear outside the conditional in OnSelectionModelLostSelection so the field is always nulled after LostSelection, preventing accidental reuse (review: copilot). - Add comment documenting the snapshot lifecycle in OnItemsViewPreCollectionChanged. * perf: defer SelectionChangedEventArgs allocations until handlers are confirmed SelectionChangedEventArgs materialized arrays via ToArray() at the call site before checking whether the routed event had any registered handlers. This allocated needlessly in the common case of no external subscribers. The event items (IReadOnlyList<object?>) already implement IList via ReadOnlySelectionListBase. RaiseSelectionChanged now accepts IReadOnlyList<object?> and casts to IList inside the HasHandlers gate, falling back to ToArray() only for non-IList enumerables.pull/21441/head
committed by
GitHub
2 changed files with 140 additions and 10 deletions
Loading…
Reference in new issue