Question

In my WPF Window_Loaded event handler I have something like this:

System.Threading.Tasks.Task.Factory.StartNew(() =>
    {
        // load data from database

        this.Dispatcher.Invoke((Action)delegate
        {
            // update UI with loaded data
        });
    });

What I want to know is what happens when the user closes the form while data is being loaded from the database and before the this.Dispatcher.Invoke routine is ran?
Will there be an ObjectDisposedException thrown? Or will the Dispatcher ignore the Invoke routine (as the window is disposed)?

I’ve tried to figure this out my self with some basic testing, but my results so far have been that nothing bad happens. No exceptions are thrown and the application doesn’t crash.

And yet I have had a couple of bad experiences before, when I used the ThreadPool for essentialy the same thing. In the Window_Loaded event handler I queued a new user work item into the ThreadPool, while the data was being loaded I pressed the Esc key (I had a Window_KeyUp event handler listen for the Esc key and if it was pressed it called this.Close()) and the application crashed when it tried to update the UI (inside Dispatcher.Invoke), since the window was already closed.

Because the Task library uses the ThreadPool behind the scenes, I’m afraid that this might happen again unless I write code to protect my application…

Let’s change the scenario a bit – what happens when the user closes the form while the UI is being updated in the Dispatcher.Invoke routine?
Will the form closing be postponed until the Invoke method has returned? Or could some exception be thrown?

If there is a possibility for exceptions to be thrown, how best to handle them?

The best that I can come up with, is to have a bool readyToClose = false; Wire up a Window_Closing event handler which checks if (!readyToClose) e.Cancel = true; Then after I have updated my UI I can set readyToClose = true, thus if the user tries to close the form too soon, it will be canceled.

Or should I instead use try { … } catch (ObjectDisposedException) { // do nothing } ?

Answer 1

In Windows Forms, calling Invoke on some control (such as your main form) will indeed throw if that control is disposed (e.g. the user closed the form). A simple way to avoid it would be using the winforms SynchronizationContext class. This works because the WindowsFormsSynchronizationContext keeps an internal control of its own, on which it calls the Invoke/BeginInvoke commands. see Exploiting the BackGroundWorker for cross-thread invocation of GUI actions on Winforms controls?

In WPF, the SynchronizationContext delegates to the dispatcher so using either of them is the same. However, since the WPF dispatcher is not disposable as controls are (it can be shut down though), you don’t have to worry about an ObjectDisposedException. However, I believe calling Invoke may hang your application if the dispatcher has been shut down (since it would wait for an operation that would never complete) – calling BeginInvoke instead should take care of that. That being said, ThreadPool threads (which are the ones created by the default Task scheduler, as in your case above) are Background threads which would not stop your process from exiting – even if they are hung on a Dispatcher.Invoke call.

In short, in both Windows Forms and WPF, using SynchronizationContext.Post (which in WPF is equivalent to Dispatcher.BeginInvoke) will take care of the general problem you’re talking about.

Let’s change the scenario a bit – what happens when the user closes the form while the UI is being updated in the Dispatcher.Invoke routine?
That can’t happen – while the Dispatcher.Invoke invoke is running the UI thread is busy, in particular it can’t process user input such as the keyboard or mouse click a user would need to close the form.