What you want is not a problem at all, but you should understand that a "selector of next form" is a control (set of radio boxed, menu, list box, etc) which needs a form to be shown. So, if you need to work with this selector first, that form should become a main form. If you don't need it anymore, you should hide it on closing, not close. This is because closing of the main form causes exit from the event loop and eventually termination of the application. Such replacement of closing with hiding is done this way:
using System.Windows.Forms:
public class MyMainForm {
protected override void OnFormClosing(FormClosingEventArgs e) {
e.Cancel = e.CloseReason == CloseReason.UserClosing;
Hide();
}
}
Use
OnFormClosing
, don't mix it up with
OnClosing
, which is there probably only due to historical reasons; no need to use it.
As after that no form will cause application to exit, you may need to cause some other form to play this role. You can call
Application.Exit
explicitly from some menu, from overridden
Form.OnClosed
, and so on.
Now, many ask how to really change the main form. This is easy, too, but does not provide very flexible technique. You can think about it, too. The form becomes main if it is used in
<application.run></application.run>
. Therefore, you have to run application several times (!). For example, in entry point, you can have three forms:
class SelectorForm : Form {
internal void AddChoice(Form[] forms) { }
internal Form ChoiceTaken { get { return } }
}
class frmSettings : Form { }
class frmMain : Form { }
Then you can move from one main form to another, depending on choice taken in first main form:
static void Main() {
SelectorForm mainForm = new SelectorForm();
frmMain newMainForm = new frmMain();
frmSettings settingsForm = new frmSettings();
mainForm.AddChoice(new Form[] { newMainForm, settingsForm });
Application.Run(mainForm);
newMainForm = mainForm.ChoiceTaken;
if (newMainForm == null)
return;
else
Application.Run(newMainForm);
}
However,
all those approaches would rather indicate bad design.
I would not pose the whole problem the way you did.
I would suggest not to go your way, no matter what technique you may use. You really don't need to chose what form to show. This is inconvenient, awkward in implementation, and even can confuse some users. I can even guess why such bad design appeared. You probably designed both forms first and created some prototype, but did not plan thoroughly what to do with those forms in your final product, but don't want to throw out your work. I would like to say: throwing out your work is one of the most important virtues in software development, and pointless "reuse" is bad thing.
There are many variants of more civilized approaches. Why not showing setting always and keeping the setting in main form? But then you should allow to change setting at any time, which would need more work. As I don't know what's in settings, I don't know if it's suitable of not.
You can keep everything in one single form. How? Look at Visual Studio. Can you notice that there is one (non-modal) form? Can you create such thing? Yes, you can.
Yes, you can use command line, so your whole application would normally run without settings, but settings are shown with certain command-line parameter. It might be suitable if settings are rarely shown. Besides, you can persist settings and load last settings on each execution, and change setting in a settings form which is show through a menu. The settings form won't be needed to show first.
And so on… The final decision can be suggested only by someone who knows your goals well. The whole idea to create a "program launcher" is already pretty suspicious, so I would question first if you really need such launcher, or is it merely an attempt to "reuse" some less then perfect applications. I don't know, really.
—SA