-3

I'm wondering what existing consumers of that interface - which will be mostly binding controls, I reckon - make use of the move and replace events of the interface that go beyond what could have been expressed with addition and removal alone.

In particular: Are they actually used, or is this simply some historical artifact?

Tseng
  • 61,549
  • 15
  • 193
  • 205
John
  • 6,693
  • 3
  • 51
  • 90
  • 1
    One could imagine that they could be used for animation effects. And you can [search the source](http://referencesource.microsoft.com/#System/compmod/system/collections/specialized/notifycollectionchangedeventargs.cs,c394c49be4a151e9,references) if you want to. – Damien_The_Unbeliever Jun 21 '16 at 07:07
  • @Damien_The_Unbeliever Wow, I didn't know about they had the sources searchable online. That's good to know. – John Jun 21 '16 at 07:11
  • Take note of the Args constructor. It is proactive in making sure that the expected data is provided with each change type. –  Jun 21 '16 at 16:04

2 Answers2

1

You will get a move action when you call ObservableCollection<T>.Move(int, int).

You can probably assume the same behavior when you replace an item. However there is no Replace method on ObservableCollection. You have to use the index accessor instead.

These action types should always be handled by INotifyCollectionChanged consumers. They are available as a hint to prevent extra operations.

Consider if you had an expensive graphical representation of a collection and you called Remove followed by Insert. The collection shrinks by one element, then immediately grows by one element. This could potentially cause two redraw of all elements after the removed index. Replace and Move let the consumers know that the size of the collection has not changed.

Community
  • 1
  • 1
Gusdor
  • 14,001
  • 2
  • 52
  • 64
  • I know all that. My question was whether it is *actually used by consumers*. – John Jun 21 '16 at 07:10
  • This answer states that as part of the interface, it absolutely should be handled. Try it with a list box. Write the event type to the debugger and observe how the list box reacts. – Gusdor Jun 21 '16 at 07:13
  • Of course it must be handled. The question is whether the list box handles it differently than the equivalent add/remove operations. Not sure how I would see just by looking at the UI. – John Jun 21 '16 at 07:42
  • @John Exactly how a control reacts to an event is largely out of our hands. All that we can assume is that the item will be moved or replaced as specified by the event. On a listbox, `Remove(index 1) -> Insert(index 1, newItem)` will visually behave exactly the same as `Replace(index 1, newItem)`. There _may_ be visible performance differences on larger collections but that is an unspecified implementation detail. Unfortunately, the only way you are going to know for sure is by testing. – Gusdor Jun 21 '16 at 08:39
0

It is certainly not and historical artifact - it's there for you so you can call Move, resp Replace and listener can react to it. Without it the interface would be incomplete regardless whether the builtin controls uses it or not.

Not sure how ItemsControl handles the CollectionChanged events, but I guess there is some logic for Move and Replace events as well.

After all, WPF is open source, why you don't you check here: http://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Data/CollectionView.cs,4270b8e1bdd07308

As you can see, CollectionView which is used by ItemsControl reacts to Reset and Move events

Liero
  • 25,216
  • 29
  • 151
  • 297
  • It wouldn't be incomplete as both move and replace can be expressed as a remove followed by and add. – John Jun 21 '16 at 07:43
  • If you called remove first, then it would mean that number of items has changed, which is not true. ListBox, for example, does not have to remove ListBoxItem and then create new, but it can reuse exiting ListBoxItem, which may have significant performance effect. – Liero Jun 21 '16 at 07:59
  • @John I'm confused. My answer told you why remove-then-add isn't good enough a solid 40 minutes before this comment and you said you knew it all already. Can you elaborate on what was not clear enough? – Gusdor Jun 21 '16 at 12:01
  • @Gusdor Whether remove-then-add is or isn't enough is precisely the question, and that hasn't been answered by anybody. Do you *know* that ListBox has this performance optimization? Is it *only* about performance? I can look in the sources and do my own research, yes. I though asking was faster, but what the hell. – John Jun 21 '16 at 12:25
  • You guys are both true. John: What Gusdor is trying to say is, that INotifyCollectionChanged is not supposed to be consumed by WPF controls only. You can use it in your business logic or even data access logic as well. In such case Move and Replace events may be crutial, thus it is definitely not historical artifact. @Gudsor: statements in your answer are correct, but I felt it won't satisfy the question. – Liero Jun 21 '16 at 12:43
  • When it comes to performance optimalization performed by listbox, it is more complicated. For example, you can turn on UI virtualization, which means that if you have biliion items in ItemsSource, but only 10 is visible at a time, listbox creates only 10 ListBoxItems. As you scroll, ListBoxItems can be recycled, with updated bindings, rather than creating new items. Another thing is, that ListBox wraps any collection into CollectionView, which may perfom filtering, grouping, sorting, etc... – Liero Jun 21 '16 at 12:52