Application.Exi t() fails

[Guinness Mann]

Pardon me if this is not the optimum newsgroup for this post, but it's
the only .NET newsgroup I read and I'm certain someone here can help me.

I have a C# program that checks for an error condition and if it finds
it it notifies the user with a MessageBox and then on the next line of
code (example in a minute) it calls Application.Exi t().

To my astonishment, I stepped through the code with the debugger, and
watched it call Application.Exi t() and then proceed to the next
statement.

Here's the code:

string s = "Some error message..."

if (!lNames.isVali dLanguage(ref strLanguage))
{
MessageBox.Show (s, "AppName", MessageBoxButto ns.OK,
MessageBoxIcon. Exclamation );

Application.Exi t();
}

As I mentioned, I stepped through the code and even stepped through it
in disassembly mode to make sure the Exit function was actually being
called.

My workaround is to replace Application.Exi t() with:

throw new System.Exceptio n();

And then catch it in Main, and call Application.Exi t() there.

[STAThread]
static void Main()
{
try
{
Application.Run (new frmITQ());
}
catch
{
Application.Exi t();
}
}

Does anyone have a clue for me? (Yes, I know I should make a custom
exception and test specifically for it, but this is just a
troubleshooting technique and I haven't completely given up on
Application.Exi t() yet.)
-- Rick

[Codemonkey]

lol. Most people have problems getting their programs to run rather than
exit ;-)

Here's an extract from the help about the Application.Exi t() method:
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~
This method stops all running message loops on all threads and closes all
windows of the application. This method does not force the application to
exit.
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~

From what I understand, Application.Exi t is not a way to stop your app there
and then (Like "End" in VB6). Instead it is used to signal all threads and
forms that they should close and allow any cleanup code to run (including
code after the call to exit).

My advice is to structure your program so that the call to Application.Exi t
is the last thing you do (i.e. Skip any following code if the logon fails).

Below is a quick example of what I mean (it was quickly put together, so
excuse bad habits)
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~
Public Sub Main()
' Run Main Application - will start the GUI loop
Application.Run (New Form1())

' Code execution will reach here when Form1 is closed or after a call to
Application.exi t and all cleanup has finished

End Sub

Private Sub Form1_Load(ByVa l sender As Object, ByVal e As System.EventArg s)
Handles MyBase.Load
' Do processing....
' Do Logon .... if it fails then exit
If Not Logon() Then
Application.Exi t()
Exit Sub
End If

' Do rest of initialization processing
End Sub
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~
"Guinness Mann" <GM***@dublin.c om> wrote in message
news:MP******** *************** *@news.newsguy. com...

Pardon me if this is not the optimum newsgroup for this post, but it's
the only .NET newsgroup I read and I'm certain someone here can help me.

I have a C# program that checks for an error condition and if it finds
it it notifies the user with a MessageBox and then on the next line of
code (example in a minute) it calls Application.Exi t().

To my astonishment, I stepped through the code with the debugger, and
watched it call Application.Exi t() and then proceed to the next
statement.

Here's the code:

string s = "Some error message..."

if (!lNames.isVali dLanguage(ref strLanguage))
{
MessageBox.Show (s, "AppName", MessageBoxButto ns.OK,
MessageBoxIcon. Exclamation );

Application.Exi t();
}

As I mentioned, I stepped through the code and even stepped through it
in disassembly mode to make sure the Exit function was actually being
called.

My workaround is to replace Application.Exi t() with:

throw new System.Exceptio n();

And then catch it in Main, and call Application.Exi t() there.

[STAThread]
static void Main()
{
try
{
Application.Run (new frmITQ());
}
catch
{
Application.Exi t();
}
}

Does anyone have a clue for me? (Yes, I know I should make a custom
exception and test specifically for it, but this is just a
troubleshooting technique and I haven't completely given up on
Application.Exi t() yet.)
-- Rick