Application.Run() Application.Exit and the 'Message Pump'

[orekin]

Hi There

I have been trying to come to grips with Application.Run(),
Application.Exit() and the Message Pump and I would really appreciate
some feedback on the following questions .. There are quite a few
words in this post but the questions are actually quite similar and
should be fairly quick to answer ...

(1) What is Happening with the Threads

In the MSDN documentation for 'Application.Run Method' it says that
the method 'Begins running a standard application message loop on the
current thread ...'

In the web pages I have found, most refer to the 'UI Thread' (for
example Alex Dong's blog http://ms.mblogger.cn/dongxun/posts/8004.aspx
and the other links that the blog refers to).

Is the 'current thread' that MSDN talks about the same as the 'UI
Thread' ?

(2) Simple Example

Lets say I build a very simple application, with a StartUp class
(contained in a cs file) and a form. The start up class just has a
few lines:
public class StartUp
{
[STAThread]
static void Main()
{
Application.Run(new ExForm());
Debug.WriteLine("Finished first Application Run, about to start
second");
Application.Run(new ExForm());
Debug.WriteLine("Finished second Application Run");
}
}

And the form - ExForm - just has a 'close button', which calls
this.close() [where 'this' refers to the form itself]

In the above example, what is happening with threads? Is there a
thread that the 'static void Main()' function runs on, that is
separate from the 'UI Thread' ?

I am very confused about the threads because I am of the understanding
that the last three lines should not execute. What I would expect to
happen is that the form would show once, then when the close button is
clicked, execution stops. However if you run the above example, the
form DOES show a second time and both the Debug.WriteLine statements
are executed.

(3) Above Example, but with Close button click event calling
Application.Exit()

Using the example in (1), Change the form to execute
Application.Exit() in the close button's click event [rather than
this.close, which I was using in the first example]. What happens
here has me befuddled ... The form does show a second time but it
flashes on and off the screen. Also, both Debug.WriteLine statements
execute .?.?.?.

(4) Another scenario to round out the question

With the form's close button click event calling Application.Exit(),
change the main function to:

ExForm myExForm = new ExForm();
Debug.WriteLine("About to show form for first time");
Application.Run(myExForm);
myExForm = new ExForm();
Debug.WriteLine("About to show form for second time");
Application.Run(myExForm);
Debug.WriteLine("All finished");

In the above example, the form shows twice and all Debug.WriteLine's
are executed.

However change the main function to:
ExForm myExForm = new ExForm();
Debug.WriteLine("About to show form for first time");
Application.Run(myExForm);
myExForm = new ExForm();
Debug.WriteLine("About to show form for second time");
Application.Run(myExForm);
Debug.WriteLine("All finished");

And the second time the form shows, it flickers on and off, however
all Debug.WriteLine's execute .?.?.?.

(5) Using a while statement works when I don't expect it to

I am of the understanding that a form needs a message pump to interact
with users. If that understanding is correct, why does this code work?

public class StartUp
{
[STAThread]
static void Main()
{
ExForm myExForm = new ExForm();
myExForm.Show();
while (myExForm.Visible)
System.Windows.Forms.Application.DoEvents();
}
}

(6) Working out Terminology

Alex Dong's web blog (http://ms.mblogger.cn/dongxun/posts/8004.aspx)
and John Conwell's article
(http://www.c-sharpcorner.com/Code/2004/Jan/Use ApplicationContextClass.asp)
provide conflicting explanations when it comes to the event hookups
between ExitThread, OnAppThreadExit, OnMainFormDestroyed and
HandleDestroyed. Could somebode please explain what event belongs to
what object and how they link together?

Thanks In Advance
Bill

 

[Dave]

I'll give it my best:

(1) What is Happening with the Threads

I don't know what they are refering to when Alex Dong's blog states UI Thread. I ASSUME it means the message-loop thread. This
thread IS the thread that the caller of Application.Run is executing on.

(2) Simple Example

Main()'s thread and the message-loop thread that Application.Run executes on are the SAME.

However if you run the above example, the
form DOES show a second time and both the Debug.WriteLine statements
are executed.

Incorrect. Application.Run will block, since it is only using a single thread (Main()'s thread).

(3) Above Example, but with Close button click event calling Application.Exit()

Application.Exit terminates the process gracefully by allowing for tear-down code to execute before disposing of the message-loop.
The thread, however, is not terminated. Application maintains internal state to prevent other message-loops being started after any
of the Application.Exit* methods are invoked. I don't know if this is the intended behavior or just a side-effect, but it prevents
you from calling Application.Run successively. Your Debug lines are still executed because they have nothing to do with the
Application class.

When you simply Close a Form, the Application does not prevent you from executing successive message-loops on Main()'s thread,
however the message-loop is automattically terminated for the Form that has been closed.

(4) Another scenario to round out the question

With the form's close button click event calling Application.Exit(), change the main function to:
...
In the above example, the form shows twice and all Debug.WriteLine's are executed.

The behavior you have described is incorrect. Try again and make sure that you have properly setup all variables that apply. Only
the first form should be displayed, and all Debug.WriteLine's should be displayed as well if you are in fact closing the first form
by invoking Application.Exit.

(5) Using a while statement works when I don't expect it to

I am of the understanding that a form needs a message pump to interact with users.
Yes.

If that understanding is correct, why does this code work?

It works because the Application class maintains internal state which it uses to determine if the current thread has a message loop
running. If not, it makes one, temporarily, for use with your Form. This can be verified by checking Application.MessageLoop for
"true" from within the context of the executing Form.

(6) Working out Terminology

What would you like to know?

--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hi There

I have been trying to come to grips with Application.Run(),
Application.Exit() and the Message Pump and I would really appreciate
some feedback on the following questions .. There are quite a few
words in this post but the questions are actually quite similar and
should be fairly quick to answer ...

(1) What is Happening with the Threads

In the MSDN documentation for 'Application.Run Method' it says that
the method 'Begins running a standard application message loop on the
current thread ...'

In the web pages I have found, most refer to the 'UI Thread' (for
example Alex Dong's blog http://ms.mblogger.cn/dongxun/posts/8004.aspx
and the other links that the blog refers to).

Is the 'current thread' that MSDN talks about the same as the 'UI
Thread' ?

(2) Simple Example

Lets say I build a very simple application, with a StartUp class
(contained in a cs file) and a form. The start up class just has a
few lines:
public class StartUp
{
[STAThread]
static void Main()
{
Application.Run(new ExForm());
Debug.WriteLine("Finished first Application Run, about to start
second");
Application.Run(new ExForm());
Debug.WriteLine("Finished second Application Run");
}
}

And the form - ExForm - just has a 'close button', which calls
this.close() [where 'this' refers to the form itself]

In the above example, what is happening with threads? Is there a
thread that the 'static void Main()' function runs on, that is
separate from the 'UI Thread' ?

I am very confused about the threads because I am of the understanding
that the last three lines should not execute. What I would expect to
happen is that the form would show once, then when the close button is
clicked, execution stops. However if you run the above example, the
form DOES show a second time and both the Debug.WriteLine statements
are executed.

(3) Above Example, but with Close button click event calling
Application.Exit()

Using the example in (1), Change the form to execute
Application.Exit() in the close button's click event [rather than
this.close, which I was using in the first example]. What happens
here has me befuddled ... The form does show a second time but it
flashes on and off the screen. Also, both Debug.WriteLine statements
execute .?.?.?.

(4) Another scenario to round out the question

With the form's close button click event calling Application.Exit(),
change the main function to:

ExForm myExForm = new ExForm();
Debug.WriteLine("About to show form for first time");
Application.Run(myExForm);
myExForm = new ExForm();
Debug.WriteLine("About to show form for second time");
Application.Run(myExForm);
Debug.WriteLine("All finished");

In the above example, the form shows twice and all Debug.WriteLine's
are executed.

However change the main function to:
ExForm myExForm = new ExForm();
Debug.WriteLine("About to show form for first time");
Application.Run(myExForm);
myExForm = new ExForm();
Debug.WriteLine("About to show form for second time");
Application.Run(myExForm);
Debug.WriteLine("All finished");

And the second time the form shows, it flickers on and off, however
all Debug.WriteLine's execute .?.?.?.

(5) Using a while statement works when I don't expect it to

I am of the understanding that a form needs a message pump to interact
with users. If that understanding is correct, why does this code work?

public class StartUp
{
[STAThread]
static void Main()
{
ExForm myExForm = new ExForm();
myExForm.Show();
while (myExForm.Visible)
System.Windows.Forms.Application.DoEvents();
}
}

(6) Working out Terminology

Alex Dong's web blog (http://ms.mblogger.cn/dongxun/posts/8004.aspx)
and John Conwell's article
(http://www.c-sharpcorner.com/Code/2004/Jan/Use ApplicationContextClass.asp)
provide conflicting explanations when it comes to the event hookups
between ExitThread, OnAppThreadExit, OnMainFormDestroyed and
HandleDestroyed. Could somebode please explain what event belongs to
what object and how they link together?

Thanks In Advance
Bill

 

[orekinbck]

Hi Dave

Thanks for your response - apologies for taking so long to reply, I
decided to take a detour to Threading, as I thought that might help me
with this topic.

With your response and my detour to Threading, I'm more comfortable,
I just have 3 more 'itty bitty' questions that I hope will clear
the confusion I have over Application.Exit() ....

As before, set up a project with one form, and that form just has a
close button. In the close button's 'on click' event handler,
just type:
this.close();

Add a class to the project and put in the start routine:

public class StartUp
{
static void Main()
{
//This should 'block' until the user clicks the close button
in the form
Application.Run(new ExForm());
//Should this second call to Application.Run work ? It does!
Application.Run(new ExForm());
Debug.WriteLine("Finished Main");
}
}

At this point the application should consist of a form - ExForm, and
a StartUp class.

(1)

In the above example, you should find that a form shows, and code
execution is "blocked" until you click close. After clicking
close, a second form shows, and code execution 'blocks' until you
click close. Then finally, the application terminates. Confirmation
Question - The closing of the first form does not 'mortally
wound' the message pump and it can get started again for the second
call to Application.Run?

(2)

Keep everything the same, but in the form, change the close button's
'on click' event handler to:
Application.Exit();

In this example, you should find that the first form shows, and code
execution is "blocked" until you click close. After clicking
close, a second form "flashes" on and off the screen. Confirmation
Question - The closing of the first form causes
'Application.Exit()' which seems to 'mortally wound' the
message pump. When the second call to Application.Run occurs, the
message pump cannot be revived, and therefore code execution cannot be
blocked. Execution falls through to the debug.WriteLine and then the
end of static void Main is reached, causing the application to
terminate.

(3)

With the close button's 'on click' event handler still calling
'Application.Exit', put this code into the StartUp class:

public class StartUp
{
static void Main()
{
ExForm myExForm = new ExForm();
myExForm.Show();
Application.Run(); //This call to Application.Run should block
//Should this second call to Application.Run work ? It does!
Application.Run(new ExForm());
Debug.WriteLine("Finished Main");
}
}

In this above example, you should find that a form shows, and code
execution is "blocked" until you click close. After clicking
close, a second form shows, and code execution 'blocks' until you
click close. Then finally, the application terminates.

Unlike scenario (2), in this scenario the message pump is not
'mortally wounded ???? Is this something to do with the fact that we
show the form then call Application.Run() with no parameters ???? Que
!?!

Cheers
Bill

 

[Dave]

Hi Bill,

1)

I can't say it for sure that .NET is meant to support multiple Application.Run calls in-line. It seems to work fine, but probably
isn't the best design pattern for an application anyway. You can start a message loop on one form, and have that form "control" the
application and maintain state. It can then Hide itself and show a different Form if necessary.

FYI, you don't have to actually write this.Close in the form... it does this for you when you click the "X" or use any system
command that terminates an app. I'm just saying in case you weren't aware of this since it's an important piece of info.

2)

You have explained this correctly. It seems that Application.Exit attempts to invalidate the Application class and it's state to
ensure that the message loop will be terminated. It doesn't seem to care that you may want to use it again. Like I said in the
first answer, it may not be appropriate to start another message pump in most real-world scenerios.

3)

Good question, lol. I'd imagine that this would have the same effect as in 2, as you have, but apparently it doesn't.

I guess that when you show the first form, it's creating that *temp* pump in order to actually allow interaction with the form, but
it doesn't effect the state of the Application class. When you then call Application.Run, you aren't giving it a form, so maybe
it's just syncing-up with the previously started loop. I guess the state of the Application class is different than it is in 2,
which is why you can start another loop even after calling Application.Exit.

Summary)

Understanding the Application class and how it can be used successively to start message loops is one thing, but actually using this
logic in a real-world app is another. I think most end-users expect a single main window to open when they start an app. When they
close the app, they expect it to terminate. Opening another form and starting another app is not intuitive in the Windows
environment and so I would have to recommend that this be avoided unless absolutely necessary.

Is there a particular design that you're after or are you just curious about the Application class functionality?

 

[orekinbck]

Hi Dave

A little bit of both really. This path started when I began rebuilding
an application. The application starts through a 'StartUp class', sets
up some tasks with timers and worker threads, then shows the main form
using Application.Run(new frmMain())

The original author of the application thought that Application.Exit
was a 'Bullet in the back of the head' for the application, but we
discovered that the real bullet was Environment.Exit ... thus leading
me to try and find out exactly what is going on with Application.Run
and Application.Exit

By the by, I am working on another project that requires a login and a
splash screen. I want to be doing processing whilst the splash screen
is running. What do you think of this startup procedure ?

private static bool MinTimeElapsed = false;
static void Main()
{
//Show Login Screen
frmLogin login = new frmLogin();
login.ShowDialog();
login.Dispose();

//If successfult login, CurrentUser singleton will be populated
if (CurrentUser.Instance.LoginName == string.Empty)
{
//Failed login, lets put a bullet in this app
Environment.Exit(0);
}

//Show Splash and put in first status message
frmSplash splash = new frmSplash();
splash.Show();
splash.StatusMessage = "Loading Company Information";

//Ensure splash shows for a minimum time
System.Timers.Timer myTimer = new System.Timers.Timer();
myTimer.AutoReset = false;
myTimer.Interval =
System.Convert.ToInt64(System.Configuration.ConfigurationSettings.AppSettings["TimeToShowSplash"].ToString());
myTimer.Elapsed += new
System.Timers.ElapsedEventHandler(myTimer_Elapsed);
myTimer.Enabled = true;

// ***
// Whilst splash is showing, lets do some background work
// ***

//Load Company Information
if (loadupcompanyinfo() == false)
{
//There was a problem getting the company informatio
//The problem is logged and reported in loadupcompanyinfo()
//For our purposes, Lets just put a bullet in this app
Environment.Exit(0);
}

//Load Main Screen
splash.StatusMessage = "Loading Main Screen";
frmMain MainScreen = new frmMain();

//Wait for minimum time to elapse
while(MinTimeElapsed == false)
{
System.Threading.Thread.Sleep(250);
}

//Close splash and show main screen
splash.Close();
splash.Dispose();
Application.Run(MainScreen);
}

private static void myTimer_Elapsed(object sender,
System.Timers.ElapsedEventArgs e)
{
MinTimeElapsed = true;
}

Cheers
Bill

 

[Dave]

Looks good with a few exceptions:

1. I don't recommend using Environment.Exit in this context. Environment.Exit will kill the process, but I believe it is not a
"graceful" tear-down. I think it parallels ending a task. In other words, just write "return;" which will automattically kill the
thread after control leaves the Main method and terminate the application gracefully.

2. Implore the use of the C# using statement for your disposal code. It's definately just my opinion since it provides no real
benefit other than astestics (and of course disposal):

using (frmLogin login = new frmLogin())
{
login.ShowDialog();
}

3. You might try encasuplating your splash logic into a SplashForm control to cleanup the startup procedure. The splash screen
could also define a method which will take a delegate for background processing while it's running. Also, it will be reusable, if
you need it in another app. (In VS.NET when you add a new form, just choose Add Inherited Form and point to your SplashForm
control. This way, you are effectively seperating GUI from business logic as you can customize the appearance of the control while
it's base logic is preserved.)

4. My next comment is definately project specific, but I would think in most cases that a splash screen would appear before a login
screen. This will provide the user with some sense that the application is "doing something" while the login form is not yet
displayed, or is in the process of closing and is hidden from view. The login screen can simply pop up over the splash screen. A
better solution would be to popup the login form after the main application loads in case a user may enter incorrect credentials by
mistake, and so should have a chance to enter them again before canceling the login. A user that attempts to load the app the first
time will probably have the correct credentials anyway, so you might as well perform the prerequist setup and show the main app
before asking for the credentials. Again, application specific.


--
Dave Sexton
[email protected]
-----------------------------------------------------------------------

Hi Dave

A little bit of both really. This path started when I began rebuilding
an application. The application starts through a 'StartUp class', sets
up some tasks with timers and worker threads, then shows the main form
using Application.Run(new frmMain())

The original author of the application thought that Application.Exit
was a 'Bullet in the back of the head' for the application, but we
discovered that the real bullet was Environment.Exit ... thus leading
me to try and find out exactly what is going on with Application.Run
and Application.Exit

By the by, I am working on another project that requires a login and a
splash screen. I want to be doing processing whilst the splash screen
is running. What do you think of this startup procedure ?

private static bool MinTimeElapsed = false;
static void Main()
{
//Show Login Screen
frmLogin login = new frmLogin();
login.ShowDialog();
login.Dispose();

//If successfult login, CurrentUser singleton will be populated
if (CurrentUser.Instance.LoginName == string.Empty)
{
//Failed login, lets put a bullet in this app
Environment.Exit(0);
}

//Show Splash and put in first status message
frmSplash splash = new frmSplash();
splash.Show();
splash.StatusMessage = "Loading Company Information";

//Ensure splash shows for a minimum time
System.Timers.Timer myTimer = new System.Timers.Timer();
myTimer.AutoReset = false;
myTimer.Interval =
System.Convert.ToInt64(System.Configuration.ConfigurationSettings.AppSettings["TimeToShowSplash"].ToString());
myTimer.Elapsed += new
System.Timers.ElapsedEventHandler(myTimer_Elapsed);
myTimer.Enabled = true;

// ***
// Whilst splash is showing, lets do some background work
// ***

//Load Company Information
if (loadupcompanyinfo() == false)
{
//There was a problem getting the company informatio
//The problem is logged and reported in loadupcompanyinfo()
//For our purposes, Lets just put a bullet in this app
Environment.Exit(0);
}

//Load Main Screen
splash.StatusMessage = "Loading Main Screen";
frmMain MainScreen = new frmMain();

//Wait for minimum time to elapse
while(MinTimeElapsed == false)
{
System.Threading.Thread.Sleep(250);
}

//Close splash and show main screen
splash.Close();
splash.Dispose();
Application.Run(MainScreen);
}

private static void myTimer_Elapsed(object sender,
System.Timers.ElapsedEventArgs e)
{
MinTimeElapsed = true;
}

Cheers
Bill

 

[orekinbck]

Hi Dave

Thanks heaps for all your help!

Cheers
Bill