Question

Scenario:

• The VB 6 form has a InteropControl (WinForms).
• The InteropControl has a ElementHost
• The ElementHost has my WPF control

Everything seems to be working except that Application.Current seems to be null when I need it. All I really want to do is hook into the unhandled exception event before the first form is fully displayed.

1. In this scenario is a WPF Application object ever created?
2. If so, when it is created?
3. If not, what causes messages to be pumped?
4. What would happen if I started the Application object on a background thread?

Answer 1

First I will explain how message loops work in interop scenarios, then I will answer your questions and give a few recommendations.

Message loop implementations in your scenario

Your scenario involves three separate technologies: VB 6, WinForms, and WPF. Each of these technologies is implemented on top of Win32. Each has its own GetMessage()/DispatchMessage() loop to pump Win32 window messages.

Here is where each GetMessage()/DispatchMessage() loop is implemented:

• VB 6 implements it internally
• WinForms implements it in System.Windows.Forms.Application
• WPF implements it in System.Windows.Threading.Dispatcher

WPF Application object is optional

Your question assumes that WPF implements the message loop in the Application object. This is not the case. In WPF, all essential functions that WinForms handled in the Application object have been moved to other objects such as Dispatcher, HwndSource, InputManager, KeyboardDevice, MouseDevice, etc.

In WPF the Application object is completely optional. You can construct a complete WPF application with a complex UI without ever creating an Application object. An application object is only useful if you need one of the services it provides, for example:

• A common ResourceDictionary
• Mapping WM_APPACTIVATE message into Activated and Deactivated events
• Mapping WM_QUERYENDSESSION message into OnSessionEnding event
• Lifecycle management (Startup/Run/Shutdown/Exit)
• Automatic shutdown when the last window or main window closes
• Default icon for WPF windows
• Remembering the first window opened (MainWindow)
• Common registration for NavigationService events (Navigated, etc)
• StartupUri

The Application class also provides several useful static members such as FindResource, GetResourceStream and LoadComponent that don’t require an Application object to exist.

When you call Application.Run(), all it does is:

1. Install the mechanism to handle WM_APPACTIVATE and WM_QUERYENDSESSION, and
2. Execute Dispatcher.Run()

All of the actual message loop functionality is in Dispatcher.Run().

Registering for unhandled exceptions in WPF message loop

The Application.DispatcherUnhandledException event you were trying to use is a simple wrapper around the Dispatcher.UnhandledException event. I think they included it in the Application object because WinForms programmers expected it to be there, but your question shows that this may have backfired.

To register for unhandled exceptions from WPF’s Dispatcher, all you have to do is:

Dispatcher.Current.UnhandledException += ...;

Unlike Application.Current, Dispatcher.Current cannot be null: If you access Dispatcher.Current from a thread that doesn’t yet have a Dispatcher, one will be created automatically.

Once you have subscribed to Dispatcher.UnhandledException, any unhandled exception from a Dispatcher message loop on the current thread will cause your event handler to be called. Note that this only applies to unhandled exceptions when Dispatcher.Run() is pumping messages: When another technology such as VB 6 or WinForms is pumping messages, that technology’s exception handling mechanism will be used instead.

WPF message loop also optional

Not only can WPF run without creating an Application object, it can also function without Dispatcher.Run(), as long as another technology is pumping Win32 window messages. This is done by creating a dummy window and/or subclassing a WPF window to install a message hook. Thus no matter what message loop is pumping messages, WPF will work as expected.

In fact, when you use ElementHost, the WPF Dispatcher is not used for message pumping unless you use one of the following methods:

• Window.ShowDialog
• Dispatcher.Invoke
• Dispatcher.Run (or equivalently, Application.Run)
• DispatcherOperation.Wait

Because of this, your WPF exception handler will probably not be called. Instead you will need to install your exception handler at the VB 6 or WinForms level.

Answers to your questions

In this scenario is a WPF Application object ever created?

No.

If not, what causes messages to be pumped?

VB 6 is pumping the messages.

What would happen if I started the Application object on a background thread?

Very little:

• If you have application resources these would be created on the background thread, possibly leading to exceptions when they are used on the main thread.

• If you add a handler to Application.Current.DispatcherUnhandledException it would only apply to the background thread. In other words, the handler will never be called unless you create windows on the background thread.

• Your Application.Startup will be called from the background thread, which is probably a bad thing. Ditto for StartupUri.

Recommendation

From what you are asking it sounds like you are getting an unhandled exception during the loading of your WPF control and you want to catch that exception. In this case, the best plan is probably to wrap your WPF control inside a simple ContentControl whose constructor uses code like this to construct the child:

Dispatcher.Current.UnhandledException += handler;
Disptacher.Current.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() =>
{
  Content = CreateChildControl();
  Dispatcher.Current.Invoke(DispatcherPriority.ApplicationIdle, new Action(() => {});
});

How it works: The BeginInvoke delays construction of the child until VB 6 and/or InteropControl have completed all processing. The Invoke call after the child control is created invokes an empty action at low priority, causing all pending DispatcherOperations to complete.

The net result is that any exceptions that were thrown within or just after the constructor are now passed to your exception handler.