7

Is this senerio valid?

I have a View to maintain an Item.

I have View Model which exposes the Item Object (implements INotifyPropertyChanged) as a Property to which is View is bound.

Is it valid for me to pass the Item object to a Backgroundworker where it is modified, then raise the PropertyChanged event when the BackgroundWorking is complete?

Or should the BackgroundWorker in no way modify the Item object. I would update the existing Item object with the results passed back by the BackgroundWorker. This would be done in the RunWorkerCompleted event. But does this lock the UI thread and defeat the object of having a backgound worker?

Confused?

I'll try to explain.

The User takes an option to create an Item. I create the View and View Model. In the View model an empty Item object is created. He is presented with a View to maintain the Item. On selecting the Item Type property, this instigates a complex process to create a list of proerties to be entered by the User. I could block the UI thread whilst the list is created but this gives a poor user experience. I want to pass the processing to a background thread while keeping the UI alive. At present, I set a flag to indicate the section on the View is loading, pass the Item object to the BackgroundWorker which updates the observable collection of Properties. When the BackgroundWorking is complete I call the PropertyChanged event which updates the section of the View which is bound to the list and turn off the flag to indicate the section is loading. This seems to work with no issues. But I have a gut feeling that I should not be updating bound onjects from the View Model in a background thread.

Thanks Tim

Tim
  • 561
  • 12
  • 22

1 Answers1

8

This sounds ok. As long as your item-object is no DependencyObject, you can change the properties of them in the background worker.
DataBinding to properties of your object will work, the binding engine will do the thread-switching automatically for you.
However, dont't fill data-bound collections or manipulate properties of DependencyObjects (such as UI-Controls) in the background worker without dispatching the manipulations. This would lead to an exception.

Edit:
Only for clarification: The real question is not, if the item-object is a DependencyObject but if the property is a CLR-property or a DependencyProperty. Because DependencyProperties are bound to DependencyObjects, I often use the above simplification, but its not the full truth.
This means that if you have a CLR-property, you can set its value from a foreign thread, regardless of your class is a DepenendencyObject or not. This is a slight difference to my first statement.

HCL
  • 36,053
  • 27
  • 163
  • 213
  • WOW, super fast reply thanks. Can you explain what you mean by Dispatching the manipulations? – Tim Mar 04 '11 at 16:35
  • @Tim: Sorry my english. I mean invoking the operation with the Dispatcher of the UI-Thread. The dispatcher will schedule the execution of the operation in the right (UI) thread. http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.aspx – HCL Mar 04 '11 at 16:44
  • Thanks, just run a test and indeed I do get an error. Will investigate. – Tim Mar 04 '11 at 17:08
  • found this article seems to do the job! http://michlg.wordpress.com/2009/08/14/dispatchingobservablecollection-thread-save-observablecollection/ – Tim Mar 04 '11 at 17:26
  • Dispatching means you have to wirte something like that in your backgroundworker: Application.Current.Dispatcher.BeginInvoke(new Action(() => ...here goes what ever you want to do in the ui thread...)); – blindmeis Mar 08 '11 at 13:11