469,611 Members | 1,725 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,611 developers. It's quick & easy.

How to abort a WinForms apps with no main window

Hi all,

I have a WinForms app that has no main window (just a module with a Sub
Main). My Main routine calls a subroutine that wants to politely abort the
application rather than return to its caller. How can I do this? I tried
Application.Exit but that doesn't terminate my application.
Mar 11 '06 #1
5 2136
Hi Bob ,

Thanks for your post!

Normally, if we return the execution path to the Main method, the main
thread will exit and the winform application will exit without any problem.
This is the most recommanded way to exit an application. Can you show me
why you can not use this way?

Additionally, based on my test, Application.Exit() should work in exiting
the application. If I have misunderstood you, please provide some more
information? Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Mar 13 '06 #2
Hi Jeffrey,

Here my source code. As you can see, the program first tests to see if some
conditions are met (registry keys exist, files exist, command line arguments
make sense, etc.). If any test fails then it calls a routine whose job is
to display the error and abort the program. It aborts the program by
throwing a custom exception which is caught by exception handler. This
scheme works, but it requires some extra code (the custom exception, the
extra exception Catch clause, etc.). What I really want to do is the
equivalent of just calling the C/C++ "Exit()" function in my Abort routine.

I had originally coded this with a call to Application.Exit in place of the
Throw statement, but that statement did nothing; the Abort routine simply
returned to its caller after displaying the message box.

======================

Module MainModule

Sub Main()
Try
' Error if conditions are not met
If <some test> Then Abort("First condition is not met")
If <another test> Then Abort("Some other condition is not met")

' Do the actual work
<Do something>

Catch ex As AbortException
' <Ignore the exception and let the application exit>

Catch ex As Exception
Abort(ex.Message)
End Try

End Sub

Private Sub Abort(ByVal errorMessage As String)
<Format the error message>
MessageBox.Show(<error message>)
Throw New AbortException
End Sub

Private Class AbortException
Inherits System.ApplicationException
End Class

End Module

=====================

""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGXA03.phx.gbl...
Hi Bob ,

Thanks for your post!

Normally, if we return the execution path to the Main method, the main
thread will exit and the winform application will exit without any
problem.
This is the most recommanded way to exit an application. Can you show me
why you can not use this way?

Additionally, based on my test, Application.Exit() should work in exiting
the application. If I have misunderstood you, please provide some more
information? Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Mar 13 '06 #3
Hi Bob ,

Thanks for your feedback.

Regarding this, why not just return from Main method to exit the
application? This is the graceful and recomanded way of exiting a
thread/application. (Actually, even in C/C++, exit() is not the recommanded
way to exit the thread, because:
"When you call the exit or _exit functions, the destructors for any
temporary or automatic objects that exist at the time of the call are not
called. An automatic object is an object that is defined in a function
where the object is not declared to be static. A temporary object is an
object created by the compiler.", this may cause some inconsistent behavior
or memory leak in the 24X7 server applications.)

Exception is not a recommanded way to jump the execution path; it has some
performance hit, because exception requires some context switch to the
kernel mode.

Yes, I can reproduce out the behavior that Application.Exit() method does
not take effect in this scenario. This is because Application.Exit
internally always check an internal ApplicationContext class, which is
created after invoking Application.Run(). Because your code invokes
Application.Exit before Application.Run, this Application.Exit() method
takes no effect. If you really want to exit the current thread, you may
p/invoke ExitThread Win32 API, however, just as I original stated, it is
not an elegant API, which we should avoid in application. Returning from
Main method in normal flow is the correct way.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Mar 14 '06 #4
Thanks for the info. That helps a lot!

- Bob

""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message
news:5j**************@TK2MSFTNGXA03.phx.gbl...
Hi Bob ,

Thanks for your feedback.

Regarding this, why not just return from Main method to exit the
application? This is the graceful and recomanded way of exiting a
thread/application. (Actually, even in C/C++, exit() is not the
recommanded
way to exit the thread, because:
"When you call the exit or _exit functions, the destructors for any
temporary or automatic objects that exist at the time of the call are not
called. An automatic object is an object that is defined in a function
where the object is not declared to be static. A temporary object is an
object created by the compiler.", this may cause some inconsistent
behavior
or memory leak in the 24X7 server applications.)

Exception is not a recommanded way to jump the execution path; it has some
performance hit, because exception requires some context switch to the
kernel mode.

Yes, I can reproduce out the behavior that Application.Exit() method does
not take effect in this scenario. This is because Application.Exit
internally always check an internal ApplicationContext class, which is
created after invoking Application.Run(). Because your code invokes
Application.Exit before Application.Run, this Application.Exit() method
takes no effect. If you really want to exit the current thread, you may
p/invoke ExitThread Win32 API, however, just as I original stated, it is
not an elegant API, which we should avoid in application. Returning from
Main method in normal flow is the correct way.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Mar 16 '06 #5
You are welcome.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Mar 17 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Drew Stoddard | last post: by
1 post views Thread by Ennixo | last post: by
20 posts views Thread by Martin Rosén-Lidholm | last post: by
3 posts views Thread by Robert Brinson | last post: by
5 posts views Thread by brian.wilson4 | last post: by
10 posts views Thread by Jules Winfield | last post: by
reply views Thread by devrayhaan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.