1. Computing

A Guide to Programming 'Explicit' Validation

A companion Quick Tip to the Validation Guide

By

The first Quick Tip Validation Guide defined validation as "the process of checking whether entered data is what it needs to be for the system to work correctly." And I noted in that article that:

Windows form controls that have a CausesValidation property can fire a whole family of events when the focus shifts from the control. Microsoft calls this "implicit validation" because the events are fired "implicitly" by .NET. Microsoft refers to coding a call to the Validate or ValidateChildren method as "explicit validation".

What Microsoft calls "implicit" validation is used most often. The first article covers that and the groundwork of validation in general. Click Here to read that article and then return to this one. Implicit validation occurs when AutoValidate for the form is set to EnablePreventFocusChange (the default) or EnableAllowFocusChange. Since the article above covers that, in this article, assume that AutoValidate for the form is set to Disable so Explict validation will be required.

In the first article, I recommend coding Console.Writeline statements to confirm what is actually happening in the code. It's an old fashioned debugging technique, but it really helps me in this particular case. (Even Microsoft's examples use it!) So I coded up a program that does the trick. It consists of just three TextBox controls. But each control has a Validating and Validated event with a Console.Writeline in it. Here's a partial snippet:


Private Sub TextBox1_Validating(
    ByVal sender As Object,
    ByVal e As System.ComponentModel.CancelEventArgs
    ) Handles TextBox1.Validating
    Console.WriteLine("TextBox1 Validating")
End Sub
Private Sub TextBox1_Validated(
    ByVal sender As Object,
    ByVal e As System.EventArgs
    ) Handles TextBox1.Validated
    Console.WriteLine("TextBox1 Validated")
End Sub

Your validation code ... for example, checking to see if a phone number is in the correct format ... will normally be in one of these subroutines. In an especially complex situation, you might use both. For example, this might come in handy if you had a two stage validation. In the first article, I noted that you can set ...


e.Cancel = True

... in Validating and prevent Validated from running. Using Console.Writeline is the fastest and easiest way to check whether that actually happens.

--------
Click Here to display the illustration
--------

There are two 'explicit' validation methods:

->Validate
->ValidateChildren

Both have two overloads. Let's look at Validate first.

The Validate Method

You might think that you can trigger the execution of the Validating or Validated events by calling Validate from, for example, a Button, but you can't. When AutoValidate is set to Disable, calling Validate does nothing, even though it might appear to 'work'.

--------
Click Here to display the illustration
--------

In this case, there are two ways to trigger the execution of the Validating and Validated events. The first is to call Validate from the event subroutine handling the event. A call to Validate can be triggered by code elsewhere, but it still doesn't trigger the Validating and Validated events as shown below.

--------
Click Here to display the illustration
--------

The second is to call Validate from a container control where the controls that you want validated are child controls. In this simple example, the only candidate is the main form. But that does do the job. To illustrate the principal, I've coded a call to the Validate method from the Click event of the form.


Private Sub Form1_Click(
    ByVal sender As Object,
    ByVal e As System.EventArgs
    ) Handles Me.Click
    Console.WriteLine(
        "Calling Validate from Form1_Click: " &
        Validate().ToString)
End Sub

--------
Click Here to display the illustration
--------

(Keep in mind that this only happens when AutoValidate is Disable.)

The other Validate overload passes a boolean. The boolean tells .NET whether to check the current value of the AutoValidate property. The way this actually works isn't obvious. Passing False gives the same result that you get with no parameter at all and results in the Validating and Validated events being triggered. True checks AutoValidate so the events are not triggered. So ...

Validate(True) does not validate

and

Validate(False) does validate

(When the AutoValidate property is Disable.)

The ValidateChildren Method

For explicit validation, ValidateChildren does more what I expected Validate to do. Here's ValidateChildren responding to a button click.

--------
Click Here to display the illustration
--------

ValidateChildren is also more powerful because you can pass a parameter based on the ValidationConstraints enumeration that limits which controls will actually trigger an evaluation. The values can even be combined with a bitwise OR operation which actually results in a logical AND operation between the individual values. You can choose from:

None - validates all child controls

Selectable - validates child controls that can be selected

Enabled - validates child controls where Enabled is true

Visible - validates child controls where Visible is true

TabStop - validates child controls that have a TabStop value

ImmediateChildren - validates child controls that are directly hosted in the container, but not the children of these children

One last warning ... If, somehow, you have managed to get to the end of this article and you still don't realize that all of these descriptions apply only when AutoValidate is set to Disable for the containing form, please be advised that they do. The previous article in this two part series focuses more on validation when AutoValidate is set to something else.

©2014 About.com. All rights reserved.