Lookups: - You Don't Always Want to Validate

by Steve Parker

Published 1999-04-01    Printer-friendly version

Lookups - a subject that just never seems to go away. Given the variety of end user needs we must address, perhaps this is to be expected. Perhaps it is appropriate that it doesn’t "go away."

When I last discussed this subject (Clarion Online, 2, 1, August 1998), I claimed that there were three ways to do lookups. I described these as "Falling-Down-Easy," "A-Tad-Harder-but-More-Customizable" and "Tear-Off-Your-Shirt-Pound-Your-Chest-and-Roll-Your-Own."

Each of these ways of calling a lookup is characterized by the degree of flexibility required.

"Falling-Down-Easy" is the simplest of lookups, effected by merely filling in the blanks on the Actions tab of the Entry Properties worksheet. The important options are whether to call the lookup "When the Control Is Selected" (essentially forcing the lookup whether or not the field is required) or "When the Control Is Accepted."

"A-Tad-Harder-but-More-Customizable" uses the CallProcedureAsLookup Code Template. With this Code Template, you have embeds before and after the lookup. You can take different actions if the lookup is completed or cancelled to customize ... well, whatever you need customized.

Figure 1

"Tear-Off-Your-Shirt-Pound-Your-Chest-and-Roll-Your-Own" is the least used but most flexible technique. Because you entirely hand-code the lookup, there is little you cannot do. Not very RAD, but there are circumstances where it is the way to go. And, when you need the control and flexibility offered, there just is no substitute.

But, in that article, I forgot that, if form doesn’t follow function, it ought to.

Empty or In File

When you use any of these types of lookup, the lookup is all but mandatory. But sometimes the field is not required; you want to allow the user to leave it blank but if an entry is made, validate it. The lookup is for user convenience.

This is where things get interesting.

If you call your lookup on EVENT:SELECTED, the lookup procedure will always be called. No options, no recourse, they’re called.

When tabbing onto the control, the lookup comes up. If the field is not required, the user can cancel, leaving the field empty. The record will save. But, the lookup is still called.

Things can be made to operate as you wish if you call your lookup on EVENT:ACCEPTED. The user can leave the field blank but the lookup will be called when they complete the form.

If you uncheck the "Perform Lookup during Non-Stop Select" box ("Falling-Down-Easy" only), it will not be called when the Ok button is pressed.

Why? During Non-Stop Select (form completion), a LOOP executes any code in every embed. So, if a control is left empty and there is a lookup on it, the lookup will execute when the window is completed. Normally, this is used to prevent leaving required fields blank. By de-selecting this option, if the control was not touched, you prevent the execution of the lookup on form completion.

So, to leave a lookup field empty, a user either has to cancel the lookup (EVENT:SELECTED) or never touch the control (EVENT:ACCEPTED).

There is no use complaining; the templates are doing exactly what they should do. Regardless of the particular lookup technique used, code in EVENT:SELECTED or EVENT:ACCEPTED is supposed to execute when those events are posted. They do; end of discussion.

Not close enough?

Using the CallProcedureAsLookup Template, however, you can easily short circuit the call by embedding:

If ~pre:label Then Return Level:Notify;End

in "Code Before" (see Figure 1). You could also create two Source embeds to "wrap" the call:

Figure 2

Either of these will cause the desire effect: the lookup will occur only if the field has a value in it. And, if you also check that

~FormWindow{Prop:AcceptAll}

(where "FormWindow" is the window LABEL) the lookup cannot be called spuriously when the form is completed. This is not, strictly speaking, necessary as the check on field contents will fail, but may increase your comfort level.

The one circumstance that you want to consider is when the user makes an entry in the field, does not tab off and presses "Ok." Here, the additional check for Non-Stop mode is most useful.

So, you can make a "blank-or-select" with just a wee tweak on the standard techniques.

This is fine and well - unless you want the type of validation that provides a "select-or-enter-what-you-want," that is, a field which will accept anything the user types in but also allows selection from a validation file.

Conditional Lookups

What we really want as an additional tool in our arsenal is a conditional lookup, a lookup that does not occur unless certain conditions obtain.

It is possible to test whether the control is empty or not. It is possible to tell whether the form is in Non-Stop mode (i.e., the form has been completed and FORMWINDOW{PROP:ACCEPTALL} = TRUE).

How do you test whether the field is to accept anything the user might type? By definition, lookups require that the value be in the validation file and check that it is. Can’t have it both ways, you know.

The classic solution, indeed the only reasonable solution, is to have the user tell the program they want to select from an "approved" list. In DOS, we called these "Hotkey lookups" and there is no particular reason to change that monicker.

In a Hotkey lookup, an entry field is just a standard entry field. That is, it accepts input, any input, from the user. If the user presses the Hotkey, then and only then is the lookup called. On completion of the lookup, the selected value, if any, is assigned to the target field.

Obviously, the lookup options on the Actions tab are unsuitable (they execute automatically on tabbing on or off the control). But both of the remaining techniques are available.

Right click on the field, select KEYS or ALERT and declare the desired hotkey. Then it is a simple matter of attaching the lookup to the hotkey:

Figure 3

• Why is there no CASE KEYCODE() here?-The Alert is attached to a single field, not the window. This makes checking the KEYCODE() unnecessary. If multiple hotkeys were attached to the single field, you would need to make this check.

A nice enhancement is to provide a string like "Press Shift-Alt-Ctrl-F5 to Select." If you start the string hidden, you can unhide it when the field is selected. When the field is completed, you can re-hide it.

Summary

Well, there you have it. You can force the user to select a value. You can let them leave it blank. You can let them do as they wish (a "non-validating validation" as I once characterized it).

Unfortunately, you still can’t read their minds.

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942