Ensuring that things run on the UI thread in WPF

by

Going over each of your questions, one by one:

  1. Not quite; you should only invoke onto the UI thread when necessary. See #2.
  2. Yes, it does matter. You should not just automatically Invoke everything. The key is to only invoke onto the UI thread if necessary. To do this, you can use the Dispatcher.CheckAccess method.
  3. That is correct.
  4. Also correct, and yes, you do run the risk of less responsive programs. Most of the time, you are not going to be looking at a severe performance hit (we’re talking about milliseconds for a context switch), but you should only Invoke if necessary. That being said, at some points it is unavoidable, so no, I would not say it is bad practice at all. It is just one solution to a problem that you will encounter every now and then.
  5. In every case I have seen, I have made due with Dispatcher.CurrentDispatcher. For complex scenarios, this may not be sufficient, but I (personally) have not seen them.
  6. Not entirely correct, but this line of thinking will not do any harm. Let me put it this way: the Dispatcher can be used to gain access to the UI thread for the application. But it is not in and of itself the UI thread.
  7. BackgroundWorker is generally used when you have a time-consuming operation and want to maintain a responsive UI while running that operation in the background. Normally you do not use BackgroundWorker instead of Invoke, rather, you use BackgroundWorker in conjunction with Invoke. That is, if you need to update some UI object in your BackgroundWorker, you can Invoke onto the UI thread, perform the update, and then return to the original operation.
  8. Yes. The UI thread of a WPF application, by definition, must be running in a single-threaded apartment.

There’s a lot to be said about BackgroundWorker, I’m sure many questions are already devoted to it, so I won’t go into too much depth. If you’re curious, check out the MSDN page for BackgroundWorker class.

More Related Contents:

  1. Dispatcher.CurrentDispatcher vs. Application.Current.Dispatcher
  2. How to pass the UI Dispatcher to the ViewModel
  3. “The calling thread must be STA, because many UI components require this” error when creating a WPF pop-up Window in thread
  4. How do I get an animated gif to work in WPF?
  5. Handling Dialogs in WPF with MVVM
  6. ResourceDictionary in a separate assembly
  7. How to populate a WPF grid based on a 2-dimensional array
  8. Image UriSource and Data Binding
  9. Access parent DataContext from DataTemplate
  10. Apply stroke to a textblock in WPF
  11. Bind to a method in WPF?
  12. Replacing the WPF entry point
  13. WPF Handedness with Popups
  14. How can I read/write app.config settings at runtime without using user settings?
  15. WPF – How to force a Command to re-evaluate ‘CanExecute’ via its CommandBindings
  16. How to set and change the culture in WPF
  17. Custom MVVM implementation Vs. PRISM
  18. Lazy loading WPF tab content
  19. Going fullscreen on secondary monitor
  20. DataGridTextColumn.IsReadOnly seems to be faulty
  21. DataTrigger not firing
  22. WPF TextBox won’t fill in StackPanel
  23. How do You Create a Read-Only Dependency Property?
  24. Binding in a WPF data grid text column
  25. What is The difference between ListBox and ListView
  26. How to begin WPF development?
  27. Change selected and unfocused Listbox style to not be grayed out
  28. Default ContextMenu Style – WPF
  29. Is the CallerMemberName attribute in 4.5 “able to be faked”?
  30. How to force WPF to use resource URIs that use assembly strong name? Argh!

Leave a Comment