A common way of providing data for a listbox is the ObservableCollection. It’s easy to bind the collection to a listbox and then add items to it. But where is the AddRange(IEnumerable<T> collection) method? There is none, so all items must be added one by one. Each time an item is added, the collection notifies the listeners of the CollectionChanged property, usually some data bound controls. That means there is a lot of harmless event noise, but it still bothered me. In some cases I suspect that the performance will drop significantly, e.g. when using controls which are expensive to update several hundred times. (Note that the ListBox uses a VirtualizationPanel to maintain performance.)
So I looked up some documentation on MSDN and deceided to implement my very own ObservableList<T>, a List<T> implementing the INotifyCollectionChanged interface. It seems easy enough, just fire the CollectionChanged event whenever some items are added or removed.
This snipped shows how it works. I wrapp the regular AddRange(IEnumerable collection) method and raise the CollectionChanged event. Same procedure for the other methods which add or remove items, including the indexer property. The NotifyCollectionChangedEventArgs specifies what changed. Sometimes I don’t want to raise the event, so I provided the IsNotifying property to switch that on or off.
public
class
ObservableList
<T> :
List
<T>,
INotifyINotifyCollectionChanged
public
new
void
AddRange(
IEnumerable
<T> collection)
base
.AddRange(collection);
NotifyCollectionChangedEventArgs
e =
new
NotifyCollectionChangedEventArgs
(
NotifyCollectionChangedAction
.Add,
new
List
<T>(collection));
Now it’s time to hook up my shiny, new ObservableList<T>! That’s when WPF notified me it doesn’t like ranges.
Ranges are not supported
So what happened here? The ListBox to wich the list is data bound is being picky about kind of information I give to the NotifyCollectionChangedEventArgs. Obviously, it doen’t like range updates.
That was kind of disappointing but not as bad as I thought at first. Why is the NotifyCollectionChangedEventArgs class that elaborate in the first place?? I fixed this by raising the event slightly differently when this exception occurs.
Hi, I have tried similar approach and it improved the Performace. But, if OnCollectionChanged call/raised multiple times then its performance again gets Slow.
For example
OnCollectionChanged raised/called 1st time executed in 0.5 sec
OnCollectionChanged raised/called 2nd time executed in 1.5 sec
OnCollectionChanged raised/called 3rd time executed in 2.5 sec
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Hi, I have tried similar approach and it improved the Performace. But, if OnCollectionChanged call/raised multiple times then its performance again gets Slow.
For example
OnCollectionChanged raised/called 1st time executed in 0.5 sec
OnCollectionChanged raised/called 2nd time executed in 1.5 sec
OnCollectionChanged raised/called 3rd time executed in 2.5 sec