Open Grauenwolf opened 5 years ago
Yes! This has been extremely annoying. Being able to trigger one large change for a set of items without causing UI relayout over and over again would be a huge perf improvement. The interface completely supports this, but for some reason WPF never has. Currently our only choice is to trigger a reset event, which causes a complete relayout of all items.
The main reason for this original design is that ObservableCollection doesn't have an AddRange method
The following apis have been approved for Collection<T>
and ObservableCollection<T>
in .NET Core; though not implemented yet https://github.com/dotnet/corefx/issues/10752:
public partial class Collection<T>
{
public void AddRange(IEnumerable<T> collection);
public void InsertRange(int index, IEnumerable<T> collection);
public void RemoveRange(int index, int count);
public void ReplaceRange(int index, int count, IEnumerable<T> collection);
// These are override by ObservableCollection<T> to raise the event:
protected virtual void InsertItemsRange(int index, IEnumerable<T> collection);
protected virtual void RemoveItemsRange(int index, int count);
protected virtual void ReplaceItemsRange(int index, int count, IEnumerable<T> collection);
}
The main reason for this original design is that ObservableCollection doesn't have an AddRange method
This isn't about ObservableCollection, but about INotifyCollectionChanged interface. Any collection can implement that interface and have add-range, or be adding items in "chunks" (like incrementally loading datasources etc)
most WPF controls will throw an exception.
I was under the impression that it's "just" System.Windows.Data.CollectionView
which would need to change, and that (in theory) something else could implement System.ComponentModel.ICollectionView
to get the desired benefits.
Admittedly, however, I haven't tried it... am I mistaken?
Edit: that said, System.ComponentModel.ICollectionView
itself extends System.Collections.Specialized.INotifyCollectionChanged
, which makes me think that System.Windows.Data.CollectionView
is likely to be just the most visible of, perhaps, many places that don't support batched changes...
Could be a 6.0.0 candidate? This currently blocks the range support in .net 6 ObservableCollection
In this context, I would like to point out the following problem: https://github.com/dotnet/efcore/issues/12675 EF core uses ObservableHashSet that implements INotifyCollectionChanged. However, the ObservableHashSet is an unsorted collection and is not able to specify an index in the OldStartingIndex property for a Remove action. This leads to an exception at this point in the EnumerableCollectionView.cs: https://github.com/dotnet/wpf/blob/026f338641b847dace824f36376beae5f5ad021a/src/Microsoft.DotNet.Wpf/src/PresentationFramework/MS/Internal/Data/EnumerableCollectionView.cs#L423 In this case, the entire CollectionView would have to be reloaded.
This is one of the top-requested features in all of the world of .NET, going back many years. Offering this is crucial.
Suggestion: We don't we log an issue for each control that have a problem with multi-item changes, and that way we can start chipping away at it and hopefully get to a point where we can add AddRange
to ObservableCollection<T>
? This issue could then be the epic for the individual tasks.
@anjali-wpf @singhashish-wpf
@robertmclaws
This is a carry over from .NET Framework.
If INotifyCollectionChanged.CollectionChanged -> NotifyCollectionChangedEventArgs.NewItems has more than one item, most WPF controls will throw an exception.
The main reason for this original design is that ObservableCollection doesn't have an AddRange method and the controls assum that nothing else will support INotifyCollectionChanged.