This is a follow-up to my question, How does WPF handle CollectionChanged events for custom collections?.
According to Alex.Wei's answer (and the source code of IndexedEnumerable) WPF ignores the specifics of the NotifyCollectionChangedEventArgs
(e.g. Action
) and always reacts the same, ultimately as if Action == Reset
.
So my questions: Who uses NotifyCollectionChangedEventArgs
' features and, if I raise the event manually (for a custom class) does it make sense to specifiy the details (if they are never evaluated)? Also, why does WPF behave like this - isn't this a potential performance killer?
I am sorry if I didn't make things clear in last anwser. Actually, WPF behaves according to specifics of the
NotifyCollectionChangedEventArgs
like it means to be, andIndexedEnumerable
just a tool that letCollectionView
or other componets of WPF access to the source collections that didn't implementIList
throngh an index easily. For example, after you bind a collection toItemsControl.ItemsSource
, the things in below will happen.ItemsControl
will specify the collection as the source of itsItems
property.Items
property which is anItemCollection
will obtain aCollectionView
by callingCollectionViewSource.GetDefaultCollectionView
method.CollectionChanged
event of the source collection and act accordingly.ItemCollection
will also subscribeCollectionChanged
event of the view and act accordingly.ItemsControl
subscribeCollectionChanged
event of theItems
and act accordingly form the beginning.So, the answer to you questions is that a lot of WPF classes are using
NotifyCollectionChangedEventArgs
' features and you definitely need to riaseCollectionChanged
event correctly by providing all the details whatever you collection was implementedIList
or not.