mirror of https://github.com/icsharpcode/ILSpy.git
Browse Source
NodesInserted/NodesRemoved reported a multi-node change (a node plus its visible descendants -- a contiguous run) as a sequence of single-item Add/Remove events, but the underlying tree updates Count by the WHOLE run before they fire. A consumer that reconciles the change one item at a time and re-indexes the source mid-sequence then reads against a Count that has already dropped by the full run: Avalonia's SelectionModel does exactly this (it re-reads SelectedItems while handling each Remove), indexing past the end and throwing ArgumentOutOfRangeException out of TreeFlattener's indexer whenever a selection was live during a bulk reshape (e.g. toggling UseNestedNamespaceNodes). It only surfaced under full-suite timing, which is why it read as flaky. Raise one ranged event for the whole run instead, so the notification matches the tree's state in a single step and Count/indices stay in agreement. The indexer keeps throwing on genuine out-of-range access. Avalonia 12.4's virtualization and selection handle ranged Add/Remove (every expand/collapse exercises it); full headless suite is green.pull/3755/head
1 changed files with 12 additions and 8 deletions
Loading…
Reference in new issue