Well, see the inner exception for detail, and provide comprehensive expression information, especially the stack, and show the code where the exception was thrown; only then you can hope some help on this part.
Now, as to the opening and closing a form. Paradoxically, even thought a form can be closed,
there is no such thing as "open a form". Come to think about, how anything which was never closed can be "opened". You create a form, show it; that's all. As to the rest of the code showing, you do it all wrong. Practically, the code when you shown a form and then close is useless in nearly all cases. You rarely need to close a form; in practice, you only need to close the main form at the very end, which leads, to application exit. Let's consider different models.
First, you can let the user work with the form until all changes are done, not touching other forms. Then you need to make it
modal, which is done using
System.Windows.Forms.Form.ShowDialog
:
https://msdn.microsoft.com/en-us/library/c7ykbedk%28v=vs.110%29.aspx[
^].
If you don't want it to be modal, it's more difficult, because the use has more choices. Closing such form makes no sense at all, but the user can close it. Even it that case, it's better to handle closing it and hide it instead. Only then that form can be used later again, in the same state. This is done by handling the event
Form.FormClosing
:
https://msdn.microsoft.com/en-us/library/system.windows.forms.form.formclosing%28v=vs.110%29.aspx[
^],
https://msdn.microsoft.com/en-us/library/system.windows.forms.formclosingeventargs%28v=vs.110%29.aspx[
^],
https://msdn.microsoft.com/en-us/library/system.windows.forms.formclosingeventargs%28v=vs.110%29.aspx[
^].
This event can be cancelled to prevent actual closing. Call
Form.Hide
instead. Do it only for
CloseReason
equal to
System.Windows.Forms.CloseReason.UserCloseing
, to allow actual closing at the end of application lifetime.
Also, as in this case you end up having several non-modal forms opened at the same time, make sure you use the owner-owned relationships. It's enough to make all such forms owned by the main form:
https://msdn.microsoft.com/en-us/library/system.windows.forms.form.owner(v=vs.110).aspx[
^],
https://msdn.microsoft.com/en-us/library/system.windows.forms.form.addownedform(v=vs.110).aspx[
^],
https://msdn.microsoft.com/en-us/library/system.windows.forms.form.removeownedform(v=vs.110).aspx[
^].
It's harder to explain the change in behavior, it's easier to make the forms owned and watch the difference in behavior. Owning keeps the application integrity; you keep all forms of the same application together in Z-order. If you don't, any other application's form can get between your application's forms, which is ugly, inconvenient.
Usually, for owned forms, it comes with one more option: not showing them in a task bar:
https://msdn.microsoft.com/en-us/library/system.windows.forms.form.showintaskbar(v=vs.110).aspx[
^].
And, finally, even better idea would be avoiding those non-modal forms at all and keep all functionality in one single form (I don't count modal forms here). Instead of separate forms, you can use panels, tab page (of the
TabControl
) or something else. You can build more complex docking interface like the one of Visual Studio, but this is a very complicated work (or you can use 3rd-party solutions). Simple tabbed interface works very well.
—SA