Special-Case Validation Results for ASP.NET Server Controls
Validation ensures that what the user has entered meets criteria that you specify. In most cases, this is a straightforward operation. However, at times the situations under which input is validated introduce special conditions. It is important that you understand what those conditions are, how validation is performed, and what the results of a validation attempt can be.
Comparing Against Blank Fields
All validation controls except the RequiredFieldValidator control consider a field valid if it is blank. You must use the RequiredFieldValidator control to prevent a user from leaving a field blank. For example, if you attach a RangeValidator control to a date field, validation passes if the user enters a date in the specified range, or if the field is left blank. If you want to ensure that the user enters a date, you must add a RequiredFieldValidator control to the date field along with the range check.
Comparing Against Another Control
When using the CompareValidator control, you can specify that validation be performed against the value of another control. For example, you might have two fields for entering dates, a start date and an end date. Using a CompareValidator control, you can ensure that the start date is less than or equal to the end date.
.gif "Security note") Security Note |
|---|
User input in an ASP.NET Web page can include potentially malicious client script. By default, the page validates that user input does not include script or HTML elements. For more information, see Script Exploits Overview. |
If the validation controls are unable to resolve the value in the other control, they do not raise an error; instead, the validation check passes. This occurs if the value in the other control is missing or cannot be converted to the data type of the CompareValidator control.
The specific tests performed by these controls, and possible results, are:
If the target control entered in the originating control's ControlToValidate property does not have a value, the IsValid property is considered true and validation passes.
If the value of the target control in the ControlToValidate property cannot be converted to the appropriate data type, IsValid is considered false.
If the value of the target control in the ControlToCompare property cannot be converted to the appropriate data type, then IsValid is considered true.
Finally, if all of these tests have passed, then both controls are non-empty and can be converted to the data type, so the control performs the actual comparison and sets IsValid appropriately.
This strategy prevents multiple errors from being reported for the same invalid entry. Validation controls are designed to test and report on only one value and to be able to display as precise a message as possible when an error is encountered.
For example, in the example of the end date, imagine that the user enters an invalid start date. The user then enters an end date. When the validation check is performed (usually on the server), the same bad date could potentially raise an error both for the start date field and for the end date. To prevent this from occurring, the end-date validation—the validation dependent on another field—does not raise an error.
You should therefore ensure that you provide sufficient validation for each individual field. In the example, it would be up to you to make sure that the user has entered a proper date in the start date field. In many cases, you should include a RequiredFieldValidator control in addition to a validation control that tests the contents of a specific entry. It is also useful in some cases to add a CompareValidator control with its Operator property set to DataTypeCheck, which does a simple type check without doing a comparison to another value or control.
See Also
Concepts
Types of Validation for ASP.NET Server Controls