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