The
CausesValidation
property deserves further explanation as its
use can be a bit confusing on first acquaintance.
Imagine that the Validate event
of a control ran whenever the user attempted
to set focus away from the current control to
another control on the form.
At first glance this would not seem to be a problem. After all
you want to make sure that the control's contents are always validated, don't
you? But consider for a moment the case where the user is currently on a control
such as a TextBox with incorrect data (a misspelled password, for instance) and
has clicked on a Help button in a toolbar or on a Cancel button to abort data
entry on this form.
In such a case, do you really
want validation to occur? If validation does
occur on the TextBox control whenever a user
clicks the Cancel button, then it's possible
that focus will remain on the original control
(if there is a validation problem). In that
case the Cancel button's Click event procedure
code will never run, and the user will be permanently
trapped with focus on the offending control
(until of course the user becomes so frustrated
that he or she reboots the machine or uses Task
Manager to stop your application).
This is where the CausesValidation
property comes to the rescue. By default, a
control's CausesValidation
property is True, meaning that other controls'
Validate event will fire when users attempt
to set focus to the current control.
You should set CausesValidation
to False on controls where the user should always be able to set focus, regardless
of whether there is a problem with data validation on some other control. For
example a Cancel button should probably have its CausesValidation
property set to False, because once the user decides to cancel a data entry session,
the validity of individual data fields does not matter.
Other Field-Level Validation Techniques topics
