Elegant handling of a Collection Change that requires changes on the dispatcher thread.

Question

Here's my situation:

I've got a User interface ItemsControl "ResultsPresenter" (WPF) pulling from a ListCollectionView that uses a BindingList "Results" from a non-UserInterface class as the ListCollectionView.Source property.

Whenever I make a change to "Results" such as an add operation, I get a NotSupportedException, insisting that {"This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread."}

It looks as if this error is coming from the "Results" collection, but the error information seems distinctly WPF generated. I'd like to know why I am throwing this error, and how to resolve it WITHOUT exposing the class that contains "Results" to WPF related code.

NOTE:

This solution came about after it was causing this error while looking directly at the "Results" property for binding, the ListCollectionView was only introduced to try and remedy this situation and is more than likely not part of the problem.

Answer 1

The event raised by your Results collection is handled by the ListCollectionView to notify the UI. If this happens on a non-UI thread, you get this exception.

So you should never modify a UI-bound collection from a non-UI thread, unless it explicitly supports it. I wrote such a class that supports it some time ago, you can find it here.

Answer 2

This has been a known issue with collection changed notifications since WPF was called Avalon. See Bea Stollnitz's blog post on the subject.

You can work around it pretty easily by doing the collection changes on the dispatcher thread. Since I'm guessing you have a long running operation returning items or changes I'd recommend looking into Rx and using the ObserveOnDispatcher setting of IObservable. Rx in general makes this sort of thing much easier than it was in the past.