I find BackgroundWorker's interface inconvenient for this purpose so I prefer to stick to using ThreadPool directly.
Here's the basic idea:
public class MyViewModel
{
public SomeCollectionType<Widget> Widgets
{
get
{
if(!WidgetFillQueued)
{
WidgetFillQueued = true;
ThreadPool.QueueUserWorkItem(_ =>
{
WidgetLoadStatus = 0;
int totalCount = FetchWidgetCount();
while(_internalWidgetCollection.Count < totalCount && !AbortFill)
{
_internalWidgetCollection.AddRange(FetchMoreWidgets());
WidgetLoadStatus = (double)_internalWidgetCollection.Count / totalCount;
}
WidgetLoadStatus = null; // To indicate complete
});
}
return _internalWidgetCollection;
}
}
}
Assuming WidgetLoadStatus is a DependencyProperty that is bound from the UI, WPF's binding system takes care of the thread transitions required to keep the status bar progress display updated.
Assuming _internalWidgetCollection allows multi-threaded access and implements INotifyPropertyChanged properly, all collection updates will also result in UI updates on the UI thread.
In my actual view models there are many collections so instead of using individual properties like WidgetFillQueued and WidgetLoadStatus, I use a data structure that keeps track of all currently executing operations and computes a combined status value for display. But the above code gives the basic idea of how the threading can be implemented properly.
The above is also applicable to loading a single large object such as a file download: Instead of calling AddRange() every time, just accumulate the data until it is all downloaded, then set the property containing the data. Note that if the object itself includes DispatcherObjects it must be deserialized on the UI thread. Do this by calling Dispatcher.BeginInvoke from within the thread.