Ask the MultiValued Visual Basic Expert - #6

(as published in Spectrum magazine Jul/Aug 1997)

updated May 27, 1997
To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-97 Caduceus Consulting. All rights reserved.

Validating field data

I have a series of text boxes on a form. The first one is called PartNum and the second one is called OrderNum. I want to be able to validate that the part number is on file, and if not, then to display "Item X is not valid" and allow entry of the part number again. So in the PartNum_LostFocus event, if the part is invalid, I display the error message and then do a PartNum.SetFocus to return to that field.

What is happening, is that the error message "Item X is not valid" is displayed, but then it is executing OrderNum_LostFocus before it is going back to PartNum_GotFocus. Why does the OrderNum_LostFocus code get run? I am baffled! - J. Smith, Western Design Howden

I hear this a lot. You put some validation code in a control's LostFocus event that does a SetFocus back to that control if there is an error, and yet some other control's GotFocus or LostFocus still gets run. Here's what's happening:

Imagine that 'focus' is tennis ball that is either in one hand or the other. You write code for 'leaving-left-hand' (LeftHand_LostFocus). When you transfer the ball to your right hand, that code gets run. Also, a transfer to your right hand will queue up an event for any 'ball-arrived-in-right-hand' code (RightHand_GotFocus).

If there is an error, the 'leaving-left-hand' code says "put ball back in left hand" (LeftHand.SetFocus). But where is the ball? It's in your right hand, which means that in order for it to return to your left hand, it has to leave your right hand. That will cause any 'leaving-right-hand' (RightHand_LostFocus) code to be run! What if a different error causes that code to say "put ball in right hand"? Now you have a problem. Such dilemmas can easily cause unpredictable behavior (or worse, unstoppable looping).

So how do you solve the problem? There is no one answer, since every situation calls for a different approach. The real question should be: "How do you validate entered data in Visual Basic?" I will devote the remainder of this article to that issue.

The following guidelines apply to how and when to detect field validation errors. I won't get into how to handle the errors - that would be a separate topic entirely, (although you might want to read "About Face" by Alan Cooper for some fascinating views on error handling). I have divided the most common data validation tasks into four groups:

1. Field format validation (e.g.: date or numeric)

2. Lookup field validation (e.g.: part number)

3. Multiple field consistency validation (e.g.: state matches zip)

4. Mandatory field validation (e.g.: address required)

 

Field format validation

This type of validation usually only involves a single field. To begin with, you should attempt to prevent an error in the first place. In other words, if it is a numerics-only field, use the KeyPress event to only accept digits (and the backspace key). For date fields, you should make every attempt to accept any recognizable date. As MultiValue programmers, we used to take the entered value, ICONV it (using a "D" conversion), and check if it was null. In Visual Basic, you simply apply the IsDate() function. You can often safely use the LostFocus event for this kind of checking. Don't use the Change event - it is invoked for every keystroke and you never know when the user is finished entering their value.

 

Lookup field validation

Many fields are keys to records in your database. As above, your first task is to try and prevent an invalid key from being entered. If your keys contain only upper case letters, convert letters to upper case as they are entered. Better yet, try using a drop-down combo box or searching your database as the user types (see previous Expert article). If this is not possible, then once again you will probably want to use the LostFocus event to verify that the key exists. You may want to put in logic to ensure that the LostFocus only performs this validation if the contents of the field have changed - there's no point in re-reading the data if the user is just stepping through the field.

 

Multiple field consistency validation

There are times when the contents of two or more fields must match according to some rule. It is not advisable to perform this kind of validation in the LostFocus event. There are two reasons for this: (1) the fields should be enterable in either order – you have no way of knowing that the user has finished with one and is intending to change the other; and (2) it is not clear which field you should send the user to in order to correct the problem. Data validation involving multiple fields is usually best done when the user is saving the entire window (e.g. clicking OK). At that point, they have indicated that they are happy with all the window contents, and it is appropriate to validate the data against the consistency rules.

 

Mandatory field validation

A window that has one or more ‘mandatory’ fields (i.e. fields that must have non-null data) are also quite common. There are a number of ways to avoid this error arising at all. For example, if the user must select from one of six choices for a field, you can replace it with six option buttons and set the Value property of the most likely choice to True. It is not possible for the user to set all options to False once one of them is true.

Another strategy for enforcing mandatory fields is to set the window’s OK or Save button’s Enabled property to False until all mandatory fields are filled in. While this is a common technique, a disadvantage of this approach is that it may be difficult for the user to determine exactly what must be done in order to enable the completion button. Since you can’t detect them clicking on a disabled button, you can’t give them a message saying what’s missing.

 

In summary, data validation is a major part of what programmers do, and we have only skimmed the surface here, but I hope you picked up a few good ideas.

To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-97 Caduceus Consulting. All rights reserved.
Revised: May 27, 1997.

Return to Caduceus Consulting Home Page

Copyright 2006 intellact
Last modified: Thursday May 25, 2006