In my continuing adventures (my polite way of describing the past couple months) of Windows Mobile Development, I have found an issue today that is quite baffling. So here is the situation.
Environment:
Visual Studio 2008 Pro with targeted platform Windows Mobile 5 Smartphone
Application:
By clicking a menu item in Form 1, Form2 opens modally using ShowDialog(). Then, by clicking a menu in Form2, Form3 opens modally using ShowDialog(). So our parent/child relationship looks like this.
Form1 -> Form2 -> Form3
Form3 contains a WebBrowser control. It does not matter if the browser control is dropped on the form at design time or added dynamically at run time. The content of the browser control is set using the DocumentText property.
The Problem:
Here is where the problem occurs. When Form3 is closed, using this.Close(); Form2 also closes automatically. Through many tests, I found that anytime a form contains a WebBrowser control and the form is closed, it also closes the parent window. This only happens on the SmartPhone. Pocket PC doesn’t appear to have the issue. I first found the problem while running the application on my Samsung Blackjack 1, and confirmed the issue using the Windows Mobile 5 Smartphone emulator.
The Workaround:
I first attempted to solve the issue by disposing the browser control before closing the window and by adding the control at runtime, rather than through the designer. Neither worked. The only reliable work around was to put in a dummy form between the parent and child form. The dummy form opens the child form immediately, so the user never sees the dummy form. When the child form closes the dummy for closes from the apparent bug, and the user is back at the parent page as expected. But what happens when the bug is fixed through a service pack, or your running on Pocket PC? Well you need the form to close for you.
Naturally you would think that I will simply call this.Close() in the dummy form as soon as execution returns from ShowDialog() . However by closing the dummy form explicitly, this auto close event that seems to hang around, now impacts Form1 and the application exits.
So, I have chosen to do the auto-close using a timer. The timer is created inside the dummy form and started as soon as execution returns from the ShowDialog() to open the child form. If the dummy form closes before the timer fires (due to the bug), all is well. If you are running on PPC or a patch for this issue is found (or this is only a problem I experience because I am incredibly unlucky), The timer won’t have anything todo and goes away without needing to close the form.
The link below is a zip file containing a Windows Mobile 5 project. This project has 7 forms, with parent/child relationships like this.
Form1 -> Form2 -> Form3 -> Form4 -> Form5 -> Form6 -> Form7
Forms 3, 5, & 7 contain web browsers. Form 3 has a browser added at design time. Form 5 has a form added at run time. Closing forms 3 & 5 demonstrate the issue. Form6 is the dummy form mentioned as part of the solution. The codebehind file for Form6 contains the workaround solution with comments.
Get the sample code