“Tidiest Drop-Downs” – Part 2, Finishing TouchesPosted: August 6, 2013 | |
But there’s one problem with the technique, which is this: because the key field is the one that the user actually enters data into, it’s possible for the user also to enter invalid data. The intention is to limit the selection to items that are in the value list, but if the user double-clicks in the field and starts typing, invalid data may be left in the field. (Of course the user may, by chance, enter a valid key value – just as a chimpanzee, left to its own devices, may eventually type the Complete Works of Shakespeare. But it’s unlikely, to say the least. And I’m not for a minute implying that my users are in any way like chimps…) So anyway, we need to use a triggered script to make sure that this doesn’t happen.
On the key field, I’ll add an “OnObjectModify” script. This will run either when the user selects a key value from the drop-down list, or when s/he types in the field. The pseudocode for the script is:
Check whether the field holds a value that exists in the value list.
If so, do nothing.
If not, display an error message and offer the drop-down list again.
A couple of pre-requisites for this script;
- It has to be as portable as possible. (I don’t want to have to write a new iteration of the script for every drop-down in the system.)
- Once the script has detected invalid data in the field, I want to throw the user back into the field, complete with drop-down list displayed (without the user having to click into the field again).
So this is how it turned out in FileMaker:
Note that the script uses two custom functions, both of which can be found on Brian Dunning’s site.
- “GSP” – which gets the specified parameter from the parameters passed to the script.
- “FilterList” – which checks for the presence of a value in a given list. (It does a lot more than this if you want it to, but that’s what it does here.)
Note also that you need a “dummy” field to go to, either during or after validation. I have the dummy field (a global) parked just off the displayed area of each layout in the system – it often comes in handy.
So, the first parameter is a comma-separated list of all the (key) values in the value list that is attached to the field. (They have to be comma-separated, rather than cr-separated, so that the list will be treated as one parameter.)
The second parameter is the OBJECT NAME (not field name) of the field being validated. We need this in order to get back to the field if validation fails. So, for the script to work, you must give the field an object name.
So the script checks whether the contents of the active field exists in the list of values. If it does, fine – just go to the dummy field, and end validation.
If the value doesn’t exist, then something’s obviously wrong, so show the custom dialog, initialise the field, then go back to the field in question. Note the need to go to the dummy field first – if you don’t (i.e. if you go straight to the field being validated), the drop-down list will not be displayed – you haven’t actually left that field yet, hence the need for the little round-trip.
Note also the need to use “Go to object” rather than “Go to field”. Although we can pass the field name as a parameter to the script, we can’t use that information once we get here, because FileMaker haven’t yet come up with a “Go To Field By Name” script step.
And that’s it. A nicely portable validation script to help keep the solution free of invalid data.