阻止一个线程上的多个MessageBox而不阻塞

Question

I have registered an error handler in my application that shows a user dialog MessageBox when an unhandled exception occurs. It's connected to the Application.DispatcherUnhandledException event and thus happens on the UI thread. Now I've seen a situation where an exception is thrown regularly, once per second, and new dialogs kept popping up. I was trying to prevent this with a lock, but since it's all on the same thread, this doesn't have any effect. An additional sleep lock on the same thread obviously led to a single blocked MessageBox on the screen.

The MessageBox seems to free the UI thread for other MessageBoxes to appear. How can I prevent that without blocking the thread?

The user has the choice to continue or exit the application. When continuing, the next queued MessageBox should appear, it should not be discarded. If too many messages show up in a time, the user can still decide to exit the application.

Answer 1

The problem here is not with the message box. It is that what happens when the message box is still open, while another exception has occurred. In which case, your DispatcherUnhandledException handler gets re-entered on the same thread.

However, the user hasn't made a decision yet about the previous error, the previous message box is still waiting for his input. Your call stack looks like this:

=> DispatcherUnhandledExceptionHandler (current)
MessageBox.Show
DispatcherUnhandledExceptionHandler (previous)

Clearly, you cannot return from DispatcherUnhandledExceptionHandler (previous) , without returning from DispatcherUnhandledExceptionHandler (current) first: you're inside a nested call on the same thread. And you cannot return from DispatcherUnhandledExceptionHandler (current) without confirming this fist with the user, back to the egg.

I can think of just one way of solving this, while sticking with your question requirements. It's to display the message box on another thread and block the main thread's message loop while waiting for the user's choice. This way, no more exceptions can occur on the main thread, until you obtain the user's consent regarding the current exception:

Application.Current.DispatcherUnhandledException += (s, e) =>
{
    this.IsEnabled = false; // disable the main window
    try
    {
        var result = Task.Factory.StartNew(
            () => MessageBox.Show(
                e.Exception.Message, "Continue?", 
                MessageBoxButton.YesNo),
            TaskCreationOptions.LongRunning).Result; // this blocks
        if (result == MessageBoxResult.Yes)
            e.Handled = true;
    }
    finally
    {
        this.IsEnabled = true; // enable the main window
    }
};

This is ugly from the UI experience prospective, but it gives you the desired workflow.

Answer 2

Message boxes are still windows that run on your thread, so they have to pump window messages (a Modal Message Loop) in order to be repainted when required, moved, handle keyboard input (eg Tab to move between controls), mouse input. They still dispatch messages to other windows on the same thread, to ensure that the window that owns them is repainted. The owning window is disabled, so input messages simply result in the default sound being played, but timers will still be fired and any sent or posted messages will still be processed.

The usual source of such problems is that you have a System.Windows.Forms.Timer or WPF DispatcherTimer attached to the window. Other possibilities include background threads using Invoke or BeginInvoke to perform some operation on the UI thread.