UI elements will not update until you relinquish control of the dispatcher thread. Normally you'd do that by returning back into the event loop, which typically means just returning. But if you've got a load of work to do in a loop, then that's not really practical. So in general, you don't want to do this sort of work on the UI thread.
When you say you're "using dependency property" do you mean that your ViewModel class's properties are dependency properties? You might want to reconsider that, because it prevents multi-threaded use. If you make them ordinary, non-auto properties, you can still use data binding to connect them to the UI. To get the UI to update when the properties change, you'll need to implement INotifyPropertyChanged
, and you make your properties raise change notifications, then you'll find that you're able to do work on a worker thread as in your first example, and if you bind those properties to the UI, you won't get threading exceptions, and it'll update just fine.
(WPF's data binding system detects when a bound property changes on a thread other than the UI thread, and automatically arranges to update the UI from the correct thread. But you can't use DPs in your VM if you want to take advantage of this, because DPS have thread affinity.)
The DoEvents
style approach someone else proposed does work but it is problematic and I avoid it. It enables re-entrancy - if the user interacts with your app in a way that causes event handlers to run, they will run inside that call to Dispatcher.PushFrame
. This is not necessarily a problem, but it's very easy to get into a mess.
Yet another approach would be to do the work on the worker thread, but to use Dispatcher.Invoke
to call a method that updates the ProgressMessage
and ProgressBarValue
properties. That way, your work occurs on a worker thread (leaving the UI thread free to update), but you'll be updating those DPs on the UI thread, which avoids the error.