Question

I would like to use the BackgroundWorker to perform a database transaction from a GUI.

How can I command the BackgroundWorker to perform the work and then WAIT for the worker to complete while keeping the GUI responsive?

Do I have to use DoEvents for this purpose, or is there another way?

Answer 1

Asking “How can I command the BackgroundWorker to perform the work and then WAIT for the worker to complete while keeping the GUI responsive?” is really asking “How do I use the BackgroundWorker?”. That’s what BackgroundWorker does.

When you write a background task, you’re basically breaking up a method into four pieces:

1. Getting ready to run the task.
2. The task itself.
3. Reporting progress to the UI while the task is running.
4. Cleaning things up when the task is done.

So you’re going to need to write four methods. The first is a method that creates a BackgroundWorker, adds event handlers to its DoWork, ProgressChanged, and RunWorkerCompleted events, puts the UI into whatever state it needs to be in while the task is running, and calls RunWorkerAsync to start the task.

The other three are those three event handlers. DoWork is a DoWorkEventHandler that does the work, and that calls ReportProgress whenever it needs to report its progress to the UI. ProgressChanged is a ProgressChangedEventHandler that actually updates the UI when ReportProgress gets called. And RunWorkerCompleted is a RunWorkerCompletedEventHandler that tells the UI that the job is done.

That’s all there is to it.

Well, not quite all. First, you have to make sure that you check and handle the Error property in your completion handler. If you don’t do this, you will have no way of knowing that your do-work method threw an exception, since it’s not happening in the UI thread and thus doesn’t throw an exception that you can see. (It’ll show up in the Output window, if you’re looking for it.)

Second, you have to make sure that the DoWorkEventHandler doesn’t touch anything in the UI. This can be tricky if you’re using the MVVM pattern and you haven’t planned for this contingency, because through the magic of data binding you probably have things in your model that update the views that the UI is bound to, which means that manipulating the model in your do-work method is manipulating the UI. Assuming that you’re implementing INotifyPropertyChanged, a good way to avoid trouble here is to build a mechanism whereby your views don’t raise PropertyChanged events while a background task is running.

You also need to figure out what pieces of the UI should be disabled while the task is running. This depends on your UI. The answer might be “all of it,” and it might not. One of the things that makes using a modal form for your progress indicator attractive is that it frees you up from having to figure this out, since your entire UI is disabled while the modal form is open. If you’re disabling controls or turning off property-change notifications in the launch method, you’ll need to turn things back on again in the completion method.

And remember: any updates that the active parts of your UI make to your data model are a potential source of cross-thread data access errors. If your UI and the background thread ever update the same object, bad things happen – they’re particularly bad if you haven’t handled the Error property in your completion handler, and the cross-thread exception kills the background task without your knowing it. If it sounds like I’m dwelling on this, it’s because I’ve lost a lot of hours of my life to doing this particular thing wrong.