Ending a program while in Form_Load

[Dom]

How do I end a program while in Form_Load? I tried both this.Close(),
and Application.Exit(), but neither will just end the program there
and then. Instead, both allow Form_Load to continue.

 

[Jon Skeet [C# MVP]]

How do I end a program while in Form_Load? I tried both this.Close(),
and Application.Exit(), but neither will just end the program there
and then. Instead, both allow Form_Load to continue.

Can you call Application.Exit and then return? Making Form_Load finish
is as simple as returning from it.

 

[Jon Skeet [C# MVP]]

Well, I suppose you could just throw an exception, or just put a "return"
statement after your call to Application.Exit(). That would prevent the
rest of your Load event handler from executing.

The Application.Exit() method isn't like the old CRT "exit()" function.
It doesn't terminate the process. It just signals to the application
message pumps to stop and closes all the windows.

I'm not aware of a .NET equivalent to "exit()", though of course an
unhandled exception can terminate the application, albeit messily. You
should avoid implementing code that just terminates the process. It's
extremely unlikely that there's a good reason for wanting to do this, and
you're better off exiting your application cleanly.

Environment.Exit() is *reasonably* close to exit() I believe.

 

[Willy Denoyette [MVP]]

I'm not aware of a .NET equivalent to "exit()" [...]

Environment.Exit() is *reasonably* close to exit() I believe.

Perhaps. The docs are extremely vague on exactly how it operates, but
yes...it appears reasonably close to exit().

Still, I wouldn't recommend it as a correct way of exiting a .NET Forms
application.

Why not?
Environment.Exit performs an "orderly shutdown" of the managed execution
environment, before an orderly shutdown of the unmanaged environment is
initiated.

Willy.

 

[Willy Denoyette [MVP]]

As far as I understand it, there's "orderly" and then there's _orderly_.

I take as granted that Environment.Exit() isn't going to leave managed
stuff hanging, but it doesn't know anything about the logic or data of the
application itself. I wouldn't use exit() as a normal strategy for
exiting an unmanaged Windows application, and I wouldn't use
Environment.Exit() as a normal strategy for exiting a managed Windows
application.

Pete

Oh, but I'm not promoting this as a "normal strategy" to end an application,
and IMO this is not what the OP is after, why would he otherwise need to end
an application while handling a form_load event?.

Anyway, with Environment.Exit, there is always a possibility to perform some
"application state clean-up" by registering an AppDomain.ProcessExit event
handler, this is a reasonable strategy to apply when you have to deal with
situations where you want to terminate a process who's (damaged) state
requires it to terminate as soon as possible . This handler will be called
as a last chance to run some managed code (time constrained to a max. of 3
seconds per AppDomain), before the managed environments starts it's orderly
shutdown activity, which consists in starting the GC and the finalizer
thread and give him a reasonable chance to run the reachable and unreachable
Finalizers. So, IMO you have a fair chance to clean-up after you, if you
care.

Note that calling exit() now ((since msvcrt v 7.1 (net 1.1) ),redirects the
call into Environment.Exit whenever called from a process that runs managed
code, this is done to make it possible to start an "orderly shutdown" from a
unmanaged code.

Willy.

 

[Dom]

Let me give the full picture, in case there is a better way to handle
everything.

In a dataentry program, the Form_Load event fires up a modal dialogue
box, in which the user can enter his/her name and password, and choose
which part of the project to work on. It makes sure that the user
does not choose a part that someone else is currently working on. On
THIS form, the user can back out (in case the available parts of the
project are not to his level of expertise) by clicking on cancel.

Of course, after Cancel is clicked on, the program goes back to the
initial Form_Load, and I want to just end it there.

Dom

Still, I wouldn't recommend it as a correct way of exiting a .NET  
Forms application.  
Why not?
[...]  I wouldn't use exit() as a normal strategy for exiting an  
unmanaged Windows application, and I wouldn't use Environment.Exit() as 
a normal strategy for exiting a managed Windows application.

Oh, but I'm not promoting this as a "normal strategy" to end an  
application, and IMO this is not what the OP is after, why would he  
otherwise need to end an application while handling a form_load event?.

You're assuming he does.  All we know is that he _believes_ he does.

That said, I'm happy to amend my original statement so that rather than  
saying "a .NET Forms application" instead it says "the vast majority of  
.NET Forms applications".  If the OP has some unusual need in which he  
cannot afford to simply return from the Load event handler after calling  
Application.Exit(), then yes...Environment.Exit() may well solve this  
problem.

Pete

 

[Ignacio Machin ( .NET/ C# MVP )]

Let me  give the full picture, in case there is a better way to handle
everything.

In a dataentry program, the Form_Load event fires up a modal dialogue
box, in which the user can enter his/her name and password, and choose
which part of the project to work on.  It makes sure that the user
does not choose a part that someone else is currently working on.  On
THIS form, the user can back out (in case the available parts of the
project are not to his level of expertise) by clicking on cancel.

Of course, after Cancel is clicked on, the program goes back to the
initial Form_Load, and I want to just end it there.

Dom

Still, I wouldn't recommend it as a correct way of exiting a .NET  
Forms application.  
Why not?
[...]  I wouldn't use exit() as a normal strategy for exiting an  
unmanaged Windows application, and I wouldn't use Environment.Exit() as  
a normal strategy for exiting a managed Windows application.
Oh, but I'm not promoting this as a "normal strategy" to end an  
application, and IMO this is not what the OP is after, why would he  
otherwise need to end an application while handling a form_load event?..

You're assuming he does.  All we know is that he _believes_ he does.

That said, I'm happy to amend my original statement so that rather than  
saying "a .NET Forms application" instead it says "the vast majority of  
.NET Forms applications".  If the OP has some unusual need in which he 
cannot afford to simply return from the Load event handler after calling 
Application.Exit(), then yes...Environment.Exit() may well solve this  
problem.

Pete- Hide quoted text -

- Show quoted text -

Hi,

I think that calling Close() if the result of the dialog is not
correct will do the trick.
Also Application.Exit should do it, when the app goes to process the
next messages it will see it and will terminate the app.

Also take a look in the archives for something ilke "password dialog"
or password form

 

[Dom]

Let me  give the full picture, in case there is a better way to handle
everything.

In a dataentry program, the Form_Load event fires up a modal dialogue
box, in which the user can enter his/her name and password, and choose
which part of the project to work on.  It makes sure that the user
does not choose a part that someone else is currently working on.  On
THIS form, the user can back out (in case the available parts of the
project are not to his level of expertise) by clicking on cancel.

Of course, after Cancel is clicked on, the program goes back to the
initial Form_Load, and I want to just end it there.

Thanks for the elaboration.

Personally, I would attempt to prevent the main form from ever being  
created until you know for sure you want to display it.  I would do this 
by something along these lines:

In your main form .cs file:

     class MainForm : Form
     {
         public MainForm()
         {
             InitializeComponent();
         }

         static public MainForm Prompt()
         {
             using (PromptForm prompt = new PromptForm())
             {
                 if (prompt.ShowDialog() == DialogResult.OK)
                 {
                     return new MainForm();
                 }
             }

             return null;
         }
     }

In the Program.cs file:

     static class Program
     {
         /// <summary>
         /// The main entry point for the application.
         /// </summary>
         [STAThread]
         static void Main()
         {
             Application.EnableVisualStyles();
             Application.SetCompatibleTextRenderingDefault(false);

             MainForm main = MainForm.Prompt();

             if (main != null)
             {
                 Application.Run(main);
             }
         }
     }

Hope that helps.

Pete

Interesting. I never thought of that. I'll have to give it a try.

Dom

 

[Ignacio Machin ( .NET/ C# MVP )]

Thanks for the elaboration.

Personally, I would attempt to prevent the main form from ever being  
created until you know for sure you want to display it.  I would do this 
by something along these lines:

I agree with you. But maybe his main form is just a splash form, if so
it would make sense to display it

 

[Dom]

I'm not sure what you mean.  The OP has made it very clear that he wants 
to optionally continue with the program based on the user's response to a  
_dialog_.  I don't think there's any "maybe" about this hypothetical  
splash form of which you speak.

On the other hand, if one is talking more generally about how to display a 
splash form, sure...that's possible and wouldn't involve any conditional  
stuff based on the display of that form.  But I'm not sure how that'd be 
relevant in this thread.

Pete

Pete got it right. I don't want the main form shown at all if the
user cancels from the dialog that comes before it. The dialog gives
the user the options that are available at the moment, none of which
may be appropriate.

Pete's solution worked fine for me.

Dom

 

[Dom]

Thanks. I wasn't sure if there was some "rule" about opening forms in
program.cs or not. I used to be a VB programmer and as you've pointed out,
switching to C# isn't just about the syntax.

The reason I used a local variable and checked it before doing
Application.Run was so I could dispose of the dialog box before continuing
on my merry way. Although you're right, I could have instantiated the main
form, then checked it for null.

Thanks again.
RobinS.- Hide quoted text -

- Show quoted text -

You know what I just thought of? In Program.cs, I did this (of
course, it is much like what Pete and Robin did):

static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);

bool Cancel = false;
frmMain.frmMain_Init(ref Cancel);
if (!Cancel)
{
Application.Run(new frmMain());
}
}

This puts it in the right place (the Main Form), and it brings back
that nice Form_Init event that VB had but had to be gotten rid of in
C#. I'm a little surprised this doesn't come up as automatic code in
the IDE.