When the WPF application has initialised and is ready to display its main window, the splash screen needs to be dismissed. The easiest way to accomplish this is by having a named event that the native application creates and the WPF application sets.
Firstly, we’ll create the named event that will dismiss the splash screen. This also has the beneficial side effect that we can prevent more than one splash screen application from running at once. (Note that the WPF application will also need to ensure that only one instance runs at a time, if that is desired. On the other hand, if you want to be able to launch multiple instances of the splash screen and WPF applications at once, each will need to have a unique event.)
Once we know it’s safe to continue running, we can use the code shown in Parts I-III to display the splash screen and launch the WPF application, then wait for the “close splash screen” event to be set or the WPF application to exit; once either of these events happens, it’s time to dismiss the splash screen.
The PumpMsgWaitForMultipleObjects method has not yet been defined. It’s similar (in API) to the Win32 WaitForMultipleObjects function, but it also dispatches window messages as they arrive. Since we have created a window on this thread, running a message pump is essential. We use MsgWaitForMultipleObjects to wait for either of two HANDLEs while also being woken up when a window message arrives. (Note that this implementation is more generic than is necessary in this example: the timeout is always INFINITE, and there’s no outer message loop that would need to reprocess the WM_QUIT message.)
Lastly, the WPF application needs to signal the splash screen application to close. (Finally, some C# code!)
As long as the same name is used, the event will be shared across the two processes and the splash screen application will exit when the event is set.
On my slow XP computer, the native application displays the splash screen in well under a second, even from a cold start. Sometimes it’s necessary to drop back to native code for small feature areas with strict performance demands. Displaying UI as soon as possible when the application is launched is one of those areas; a few hundred lines of native code can result in a perceived decrease in application startup time and a better experience for the end user.
Posted by Bradley Grainger on October 01, 2008