Database Reference
In-Depth Information
Figure 17-18. Your first attempt to filter keystrokes for a field might look like this one. (You can see
the calculation formulas for each If step on page 698.) Unfortunately, this script doesn't work
quite right, since keystroke triggers fire for almost every key. This script has the nasty side effect of
blocking the arrow keys, the Delete key, and even the Enter and Tab keys, which should be valid
entries along with the data keys you want to allow.
When you test the Zip Code field script trigger, you'll see that the script is a little too ag-
gressive. Since it cancels every keystroke that isn't a number, you can't use the Delete key to
clear an accidental entry. Plus, it blocks the Enter, Tab, and arrow keys, and you can't exit the
field easily. You've created a monster—a field that can't be edited.
The fix is easy, though. If you refer back to the list of special key codes on Detecting Key-
strokes , you see that most of the special navigation keys have codes less than 31. The notable
exception is Forward Delete, which is 127. So instead of adding a special case for each and
every key, you can allow all the special keys in one block with a simple formula. Add an If
test to the top of your script, using this formula:
Code ( Get ( TriggerKeystroke ) ) < 32 or Code ( Get ( TriggerKeystroke ) ) =
127
You also need to improve your formula in the If statement that checks the Zip code's length
so it lets users highlight the text in order to delete it. Edit that calculation to add a new test:
Length ( Customers::Zip Code ) ≥ 5 and Get ( ActiveSelectionSize ) = 0
This tactic is perfectly safe because every normal key (letters, numbers, space, and punctu-
ation) has code 32 or above. You can see your new and improved script in Figure 17-19 .
Search WWH ::




Custom Search