Application.Exit()

C

Cags

Contributor
Joined
Feb 19, 2004
Messages
695
Location
Melton Mowbray, England
I've always used Application.Exit() as a way of closing down my application. It recently dawned on me however that doing so doesn't appear to call either Dispose, OnClosed or OnClosing (at least a break point doesn't stop in them) of the form which is passed to Application.Run(). Now call me niave, but I always assumed this was the case. Whilst I never realised this untill now I have never appeared to have any ill effects such as memory leaks, now is this through sheer luck or is there another explanation (such as the Disposed method being called, but after the debugger has been detached from the appliction)?

I've recently been starting todo some stuff that involves alot of API calls and I'm worried that I may leave things behind in memory that should have been dealt with. Is there one method that I can put disposal code in that is always likely to be called, or is it simply a case of ensuring I dispose of the form before calling Application.Exit()?

On a side note, is clicking the stop in Visual Studio whilst debugging the same as calling Application.Exit() or does it exit the application in a different manner? In which case similar to my early question, is there anyway to ensure a section of code is ran before the application exits when the stop button is pressed.
 
Application.Exit() is the rude way of tearing down the application. It doesn't ask the currently running form(s) to close, it just yoinks the environment out from under them which is why your breakpoints aren't getting hit. If you've not noticed any problems then you're lucky and all the things that aren't getting disposed were only scoped to your application so when the process dies they're effectively dead.

Form.Close(), it closes the form and if that is the MainForm of the Application the Application will cleanly shut down the messageloop and continue through Main which is normally empty. Think about it. You started the application by creating a form and telling the application object to start sending messages at it (this is what Application.Run does) so to shut it down politely the form should tell the application that its all finished now thanks and then go away. Doing it externally from Application.Exit() isn't the form telling the application its finished.
 
Application.Exit (like End in VB6) is considered bad practice. The correct way to end an application is to get to the end of your Main, which, like wraith said, is done by closing your main form, which returns control to your Main.

According to MSDN, Application.Exit does not actually abruptly force the program to terminate. It tells all message loops to terminate and after they finish processing messages all the windows are closed. This naturally causes Application.Run to return control to your Main, allowing the program to terminate. All finalizers should be closed, and fall-back finalizers should still call the appropriate Dispose methods for you.

In version 2.0 of the framework, you can actually stop the application from closing by handling the Form.Closing event and setting e.Cancel to true. This is probably a bad idea, though, since the order that forms are closed is most likely undefined, which means you never know which forms will be left open and which ones won't.
 
You can also handle the closing event in 1.1 - that's how I'm trapping any forms with unsaved data.

The other way to handle shutdown of the app would be to add each opened form to an array defined by sub main then close them programmatically depending on what type they are.

Based on the line of thought going on here, though ... does closing the form also dispose all of the objects stored in the controls collection, or do we need to systematically loop through everything and dispose them properly?


Paul.
 
Components and controls should be disposed automatically when the form is disposed. If you don't call Form.Dispose explicitly the form's finalizer should do it for you (but, of course, that is a fallback).
 
Back
Top