The Causes Validation Property

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.

0 0

Post a comment