Abort form closing

[Aleksey Timonin]

Hi guys,
I show my Form in dialog mode. So I have "Ok" button on it with DialogResult
= Ok. What is the right way and how can I abort form closing from the button
click event.

Thanks a lot
Aleksey

 

[Bob Powell [MVP]]

You can service the FormClosing event and set the Cancel property in the
evant argument to true.

private void Form1_FormClosing(object sender, FormClosingEventArgs e)

{

e.Cancel = true;

}


--
--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Alec MacLean]

The capture of the FormClosing event is a good thing to be aware of.

There are also some complementary methods that involve not setting the
form's DialogueResult property to your OK button in the designer.

There are several different approaches you could take.

Start with NOT setting the form's property for DialogueResult at all, but
control this value in code instead, along with some business logic that will
determine if the correct state has been reached.

1. Have your OK button Not Enabled by default. On the other controls on the
form (e.g. your textboxes, combolists, etc), use their various change events
to determine if the correct state to allow the OK button is met and toggle
it's enable state. You can also then set the form's DialogueResult state in
the OK button click event handler.

In this approach, you are visually telling the user that the form is not
ready to close until the OK button becomes enabled by setting correct values
in the form. This is good UI practice - look at what commercial grade
programs do in this regard. It should also help you to create more
maintainable code by breaking down the validations into discrete blocks.
For example, say you have a textbox that you want to capture an email
address in; you can apply a Regular Expression validation to check if a
valid email format has been used. This type of validation can be set to
fire on every character change in the textbox by using the TextChanged
event.

2. In the method for handling your OK button, check for whatever it is you
want them to do before allowing the form to close. If conditions are not
met, don't call the close method. If they are met, set the form
DialogueResult to OK.

This is similar to approach 1, but uses a monilithic type of validation
check. For small forms this may be OK, but I would suggest approach 1 is
preferable due to the UI feedback cues it also provides

Hope that helps

Al

 

[Serge Wautier]

Hi Alec,

No offense intented but method 1 has shown its limits for long: As long as
user can't click OK, there's no way to tell him what's wrong in his input. I
prefer to let him click OK and reply by a messagebox saying "the password
confirmation doesn't match the first password" instead of letting him look
for the problem somewhere and get upset soon.

My 2 cents,

 

[Alec MacLean]

No offense taken Serge - we all have our preferred methods of doing things.

I would normally use the ErrorProvider control to visually indicate to the
user both the control needing a corrected value, as well as tooltip text
(part of the ErrorProvider control) that indicates why there is a problem.
This visually takes the user directly to the area needing attention. It
also helps make programs more accessible to users who have visual
impairment, whereas a monolithic messagebox covering what may be a large set
of error conditions does not.

Your approach is perfectly fine for very small forms such as the login form
you suggest, but if you are validating a longer data entry form (say 30
values), then you could end up with a very long message box (possibly taller
than the user's screen res will display), plus the code for formatting it
all.

Al