views:

336

answers:

1

I've got an ObservableCollection<A> a_collection; The collection contains 'n' items. Each item A looks like this :

public class A : INotifyPropertyChanged
{

    public ObservableCollection<B> b_subcollection;
    Thread m_worker;
}

Basically, it's all wired up to a WPF listview + a details view control which shows the b_subcollection of the selected item in a separate listview (2-way bindings, updates on propertychanged etc.). The problem showed up for me when I started to implement threading. The entire idea was to have the whole a_collection use it's worker thread to "do work" and then update their respective b_subcollections and have the gui show the results in real time.

When I tried it , I got an exception saying that only the Dispatcher thread can modify an ObservableCollection, and work came to a halt.

Can anyone explain the problem, and how to get around it?

Cheers

+3  A: 

Technically the problem is not that you are updating the ObservableCollection from a background thread. The problem is that when you do so, the collection raises its CollectionChanged event on the same thread that caused the change - which means controls are being updated from a background thread.

In order to populate a collection from a background thread while controls are bound to it, you'd probably have to create your own collection type from scratch in order to address this. There is a simpler option that may work out for you though.

Post the Add calls onto the UI thread.

public static void AddOnUI<T>(this ICollection<T> collection, T item) {
    Action<T> addMethod = collection.Add;
    Application.Current.Dispatcher.BeginInvoke( addMethod, item );
}

...

b_subcollection.AddOnUI(new B());

This method will return immediately (before the item is actually added to the collection) then on the UI thread, the item will be added to the collection and everyone should be happy.

The reality, however, is that this solution will likely bog down under heavy load because of all the cross-thread activity. A more efficient solution would batch up a bunch of items and post them to the UI thread periodically so that you're not calling across threads for each item.

The BackgroundWorker class implements a pattern that allows you to report progress via its ReportProgress method during a background operation. The progress is reported on the UI thread via the ProgressChanged event. This may be another option for you.

Josh Einstein
what about the BackgroundWorker's runWorkerAsyncCompleted? is that bound to the UI thread as well?
Maciek
Yeah the way BackgroundWorker is designed is to use the SynchronizationContext.Current to raise its completion and progress events. The DoWork event will run on the background thread. Here's a good article about threading in WPF that discusses BackgroundWorker too http://msdn.microsoft.com/en-us/magazine/cc163328.aspx#S4
Josh Einstein
This answer is beautiful in its simplicity. Thanks for sharing it!
Beaker