How to abort a WinForms apps with no main window

11 Mar 2006 8:18 PM

Bob Altman

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.

13 Mar 2006 6:08 AM

Jeffrey Tan[MSFT]

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.

13 Mar 2006 5:27 PM

Bob Altman

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
Show quoteHide quote

news:%23v97WSmRGHA.1484@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.
>

14 Mar 2006 6:16 AM

Jeffrey Tan[MSFT]

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.

16 Mar 2006 3:40 PM

Bob Altman

Thanks for the info. That helps a lot!

- Bob

""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message
Show quoteHide quote

news:5jiwP7yRGHA.7004@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.
>

17 Mar 2006 1:36 AM

Jeffrey Tan[MSFT]

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.