How often do you use System.Component.BackgroundWorker in your UIs ? (if ever)

Question

I am sure a responsive UI is something that everyone strives for and the reccomended way to do stuff is to use the BackgroundWorker for this.

Do you find it easy to work with ? Do you use it often ? Or do you have your own frameworks for lengthy tasks and reporting process.

I have found that I am using it quite a lot and even using its delegates wherever I need some sort of progress reporting.

Answer 1

I use it quite often for tasks such as progress indication and background data loading\processing.
Recently i found use case that is not supported out of box. It's "Overridable Task". However Patric Smacchia come up with nice solution.

Answer 2

BackgroundWorker makes things a lot easier. One thing I found the hard way is Backgroundworker itself has thread affinity even though it is supposed to hide the thread switching problem. It does not automatically switch to the UI thread in every case. It needs to be created and run from the UI thread for thread switching to happen properly.

Answer 3

I've used it once and was quite happy with it. Often, there is no need for "big" multithreading, but only for 2 Threads (UI and Worker), and it works really well without having to worry too much about the underlying Threading Logic.

Answer 4

Multithreaded programming is hard to grasp in the beginning (and veterans still fail sometimes) and BackgroundWorker makes it a bit easier to use. I like the fact that BackgroundWorker has functionality which is easy to implement but even easier to wrongly implement in a subtle way, like cancellation. I use it if I have and need a progress update, so I can display a meaningful progress bar.

If not, I use a Thread (or borrow from the ThreadPool), because I don't need all the functionality of BackgroundWorker and am proficient enough with threads to start a Thread and wait for it to stop.

As for delegates for non-related tasks, I use those of the Thread classes, like plain void ThreadStart(), or I create my own.

Answer 5

@Gulzar Thank you for this piece of info : It needs to be created and run from the UI thread for thread switching to happen properly.

One thing to watch for when using a background worker that I have found is exception handlings.

If an exception is thrown on the async process it will not throw an exception to the main thread, the process will finish and BackgroundWorker RunWorkerCompleted event will fire with the error being hidden in the RunWorkerCompletedEventArgs.Error.

I like the fact that BackgroundWorker has functionality which is easy to implement but even easier to wrongly implement in a subtle way, like cancellation.

Answer 6

My biggest issue with the background worker class is that there really is no way to know when the worker has finished due to cancellation. The BackgroundWorker does not expose the thread it uses so you can't use the standard techniques for synchronizing thread termination (join, etc.). You also can't just wait in a loop on the UI thread for it to end because the RunWorkerCompleted event will never end up firing. The hack I've always had to use is to simply set a flag and then start a timer that will continue checking for the background worker to end. But it's very messy and complicates the business logic.

So it is great as long as you don't need to support deterministic cancellation.