Form navigation

[Trevor]

What is the best practice for Form navigation for a Compact Framework
application? I have implemented a simple function in Program.cs to switch
the screens (see below for implementation). I have noticed if I close my
application through Start > Settings > Memory > Running Applications, all of
the Forms close, but the process remains running and I have to kill it using
Remote Process Viewer.

I am starting out the program with a Application.Run(new LogonForm()) and
then I am calling the function below to show new screens as the application
runs. I have noticed the program only keeps running after I switch to a
second form. That is, if I close the LogonForm using Running Applications,
the process exits cleanly as long as I don't switch to a second form using
my function. I imagine this means I am not doing something the preferred
way. I decided to use Show instead of ShowDialog because I have no need to
keep the LogonForm active for the duration of the program.

Here is the function I am using to switch screens:

public static void ShowScreen(Form newFrm, Form oldFrm)
{
if (newFrm != null)
newFrm.Show();
else
throw new ArgumentNullException();
if (oldFrm != null)
{
oldFrm.Hide();
oldFrm = null;
}
else
throw new ArgumentNullException();
}

I call it like this when I want to switch screens:

Program.ShowScreen(new ManifestForm(), this);

 

[Simon Hart [MVP]]

That code looks really dodgy.

You are setting the second form to null after hiding it. Why are you doing
this?

Usually if your app is still running after killing it using the memory
applet it's because you still have some threads running.

 

[Chris Tacke, eMVP]

You're calling Hide (as opposed to Close) and then setting it to null?
That's hugely suspect - that's going to leave live but inaccessible roots
and you're at the whim of the GC to clean that up - after 2 collections at
that.

It's also a pretty ugly architecture for a form to pass a reference to
itself somewhere, then have the thing it called set the Form to null - no
idea how teh stack might unwind on that. In short, I'm surprised the only
errors you have are that it doesn't terminate. It just proves how amazingly
forgiving a managed environment really is.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Trevor]

I am setting the Form to null so the GC collects it. I am not trying to
re-use these forms and many of them contain a List<> of objects for quick
validation. The idea was those List collections may use a lot of memory if
there is a lot of data, and I don't need them after I switch a form, so the
system should clean them up as soon as possible. If I called Form.Close or
Form.Dispose instead of setting it to null then the whole program exits when
I try to switch forms.

This book I have contains a couple of pages on Form navigation. They
recommend using Form.ShowDialog to show the "main window" in Main(). The
problem is that I don't have a "main window", or if I could consider a
window to be the main window, it would require the user of the application
to go through several screens before they even get there. I only have one
or two situations where the user might want to press cancel and return to
the previous form. ShowDialog is good for those cases, but it is not good
when I want to show a form without going back because then the old forms
stay in memory.

 

[Chris Tacke, eMVP]

I'd say the book you have is wrong. You need to understand how
Application.Run works and how messages get dispatched.

The short of it is that whatever Form gets passed into Run is the "holder"
of the message pump. When that Form closes, Run returns and the app will
exist (unless there's code after the Run call).

ShowDialog should be used for dialogs.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Simon Hart [MVP]]

Usually you would start the message pump with your main window then within
your main window load; for example your login screen or whatever. Once you
have the required information from these initial screens, control returns to
the main window class (that hasn't been shown yet) for which then you'll send
the ShowDialog to the main window.


--
Simon Hart
Visual Developer - Device Application Development MVP
http://www.simonrhart.com