Trying to close the form after the next is shown in C # cf

Question

I’ve been learning Android lately and I tried to port one of my features to a compact C # environment.

What I did was create an Abstract class, which I call Activity. This class is as follows:

internal abstract class Activity { protected Form myForm; private static Activity myCurrentActivity = null; private static Activity myNextActivity = null; internal static void LoadNext(Activity nextActivity) { myNextActivity = nextActivity; if (myNextActivity != null) { myNextActivity.Show(); if (myCurrentActivity != null) { myCurrentActivity.Close(); myCurrentActivity = null; } myCurrentActivity = myNextActivity; myNextActivity = null; } } internal void Show() { //PROBLEM IS HERE Application.Run(myForm); //myForm.Show(); //myForm.ShowDialog(); // } internal void Close() { myForm.Close(); } internal void GenerateForm() { ///Code that uses the Layout class to create a form, and then stores it in myForm //then attaches click handlers on all the clickable controls in the form //it is besides the point in this problem } protected abstract void Click(Control control); //this receives all the click events from all the controls in the form //it is besides the point in this problem } 

I have a problem running part of the Show() command

Basically, all my classes implement the above class, download the xml file and display it. When I want to switch to a new class / form (for example, going from ACMain to ACLogIn) I use this code

 Activity.LoadNext(new ACLogIn); 

It is supposed to load the following form, show it and unload the current form

I tried these solutions (in the Show() method), and here is the problem with each

• using myForm.ShowDialog()
  This works, but blocks execution, which means the old form does not close, and the more I move between the forms, the more the process stack grows.

• using myForm.Show()
  This works, closes the old form after showing the old one, but immediately after that closes the program and ends it

• using Application.Run(myForm)
  This only works in the first form loaded, when I go to the next form, it shows that it throws an exception: "The value is not in the expected range"

Can someone help me fix this or find an alternative?

Answer 1

If you really created your own infrastructure for this navigation, you need to think again. The instance of the form that passed in Application.Run should never be closed - when this happens, Application.Run terminates the execution and (usually) unloads the static void Main entry point, and the application terminates.

What I suggest is that you change your activity to either UserControl:

 public abstract class Activity : UserControl { .... } 

or making up one

 public abstract class Activity { private UserControl m_control; .... } 

Then, instead of closing and displaying the forms, the parent of all operations inside the main form as a container.

As a fair warning, this will be tricky when you start wanting to show things in a Tab motif instead of a stack or have split views. Frames seem simple to create, but they are not, I would at least think about using something already done, if you have no good reason to want to drop your own.

Answer 2

Application.Run typically used with overloading, which takes a Form parameter. This will be the "main" form, which will be responsible for launching / displaying other forms. This "main" form may be "hidden." But, I think this is a little uncomfortable.

In addition, you do not need the main form, you can use Application.Run() to start the message pump to process Windows messages; but then the thread is busy processing messages and cannot display dialog boxes (they should be displayed in the thread that runs Application.Run ). You can get around this by creating one or more form objects before calling Application.Run , and these form objects can create a Timer object that calls Form.Show() or Form.ShowDialog() in the Timer.Tick event Timer.Tick , so for the form after calling Run . I think this is also a bit uncomfortable.

Both of these solutions see how you expect to use Windows and WinForms; therefore, I think you need to think about redesigning this application to work with how Windows and .NET work.