It turns out that you shouldn't ever construct a WPF window inside the constructor of another. If you do, the application will hang indefinitely on exit. That is, the first window will disappear, but the process will continue running.

The following code can be used to reproduce the hang:

    public partial class Window1 : Window
    {
        private Window2 window2;

        public Window1()
        {
            InitializeComponent();
            window2 = new Window2();
        }
    }

You can also see a screencast of this bug in action, courtesy Jing (I'm very pleased with Jing; I also used it to create the OBZTime screencast and wholeheartedly recommend it for quick & easy screencasts if you can handle the Jing logo at the end).

Update 14/08/2008: There's a discussion thread on this issue on MSDN Forums with details on how to solve this problem.

It turns out that I was dead wrong about the cause; it has nothing to do with the nested constructors. I was counting on the application closing when the last shown window was closed, but instead the default behaviour is to count constructed windows.

Personally I think Hua was being a little generous when he said that to have this behaviour as default is "debatable" :-)

Anyway, the fixed code looks like this:

    public partial class Window1 : Window
    {
        private Window2 window2;

        public Window1()
        {
            InitializeComponent();

            Application.Current.ShutdownMode = ShutdownMode.OnMainWindowClose;
            window2 = new Window2();
        }
    }

I know I've been promising a full NPresent tutorial for a while now - and I'm still planning to post one. In the meantime however I thought I'd quickly demonstrate how I've been using C# Script (a great scripting engine for C# developed by Oleg Shilo) to automate WPF smoke-tests as part of our NAnt build. This required a new release of NPresent that can attach to existing windows; you can get it here.

I've finally had the time to release Beta 1.0 of NPresent, my open-source framework for test-driven development of WPF applications. When I get the time I'll add a tutorial to the Wiki, although it should be pretty easy to figure out how to use it by taking a look at the test source code.

NPresent is coming along, albeit slowly.

There's an application skeleton and base test class in place, and more guidelines on the Wiki. More functionality will be coming soon; if you'd like to participate in the development of NPresent please email me. If there are any features you'd like (no matter how 'out there' they seem), either email me or add a feature request to the list.

If you're using PInvoke to call Win32 API functions and start seeing strange return values, make sure you're using the correct Point type. For example, the following code:

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
internal static extern int GetCursorPos(ref Point lpPoint);

... takes a System.Drawing.Point, not a System.Windows.Point. This may well bite you when you're coding against WPF and have references to WindowsBase.dll but not System.Drawing.dll. The code will compile and run but you'll see very strange values being returned as a result of the two structures not being equivalent.

This is easily enough fixed by qualifying the type:

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
internal static extern int GetCursorPos(ref System.Drawing.Point lpPoint);