Validation With Script Triggers

With the post-DevCon madness coming to a slow end, I’m excited to announce that I’ll be traveling the last week in September and participating in the West Coast FMPug Tour! What’s the schedule you ask? Here it is:

• September 26 – Seattle
  
• September 27 – Portland
  
• September 28 – San Francisco
• September 29 – FileMaker Inc. (the Wedge in Santa Clara)
  

With that said, I’d like to share with you one of the techniques that I’ll be presenting at the FMPugs – and that’s controlling the user via script triggers. Now I say this cautiously, as I can feel Steven Blackwell rolling his eyes at me from 1500 miles away, concerning himself with Security (and rightfully so!). I do not think that script triggers should be the only means for controlling users and the data they enter, but I do believe that script triggers can give the user a more pleasant experience than JUST validation. I implemented this technique for one of our development customers and they are very happy that their solution is intuitive and the data being entered is accurate. So onward! One of my critiques of validation error messages is their… simplicity. You get a dialog box and a couple of buttons – that’s it. With this example, we can use script triggers to give the user more information and allow them to enter data accurately.

Example 1: Better Dialog Messages

A great use of script triggers is OnObjectValidate, which runs right before validation occurs, which also means the user hasn’t left the field. Imagine having a field where the user has to enter a number between 0 and 100 and the user enters 150. With validation turned on, an error message will show up, but we can add a little more finesse with a script trigger. Here’s what the script looks like:

You’ll notice the use of Get ( ActiveFieldName ) and Get ( ActiveFieldContents ) – the goal here is to abstract the script so that it can be reused in multiple places. In other words, by not tying the script to a specific field, this script can be applied to multiple fields that require the same type of validation. So in plain English, what is the script doing?

1. Checking to see if the value in the active field is between 0 and 100
2. If the value is not between 0 and 100, a dialog box shows up with a global field in it. The user can then enter a value in the dialog.
3. If the user enters a number between 0 and 100, the active field gets set to the value in the global field and the script ends.
4. If the user enters a number outside of 0 and 100, the custom dialog keeps showing up.

Here’s what the dialog box looks like:

Example 2: Locking the Keyboard

My customer said to me, “I don’t want the user to even be ALLOWED to enter the wrong values with the keyboard.” This is a different approach to a similar problem. Instead of telling the user that he or she did something wrong after the fact, limit what the user can do during data entry.

In this same example, here’s a script that doesn’t allow the user to enter anything but numbers and periods (for decimal places). Now this was initially tricky in that I first wrote this to ONLY allow numbers and periods, but then realized that those aren’t the only keys a user might need while in a field. The other keystrokes that I had to allow were the tab key, and enter key, and the arrows (for navigating within the field).

Note: The script was put into a text editor for ease of reading.

The Let function is the most complex part of this script so let me break out that calculation:

 Let (
	c = Code( Get( TriggerKeystroke ) ) ;
	
	Length ( Filter (  Get ( TriggerKeystroke )  ; "0123456789." & If ( Get ( ScriptParameter ) = "dash" ; "-" ; "" ) ) ) > 0 or c = 9 or c = 10 or c = 28 or c = 29 or c = 30 or c = 31
)

The variable “c” is going to equal the numeric representation of the keyboard key.

The line starting with “Length” is checking to see if the key was a number, a period, and if the script parameter is the word “dash” then the dash, too.

As for the other codes, here’s the legend:

• 9 – Tab
• 10 – Enter (number pad)
• 28 – Left arrow
• 29 – Up arrow
• 30 – Right arrow
• 31 – Down arrow

The easiest way to tie the keyboard to a number is through the Keystroke Companion by SixFriedRice. A must-have in a FileMaker developer’s toolbox. So the script checks to see if the user hit an appropriate symbol or an appropriate keyboard key. If the user has, the script exits with a 1, meaning “OK”. If the script exits with a result of 0, the script trigger will prevent the keystroke from being executed. The cool thing about OnObjectKeystroke is that the script runs before the key is entered into the field, so the script has control whether or not the key shows up.

Clean. Elegant. User friendly.

The nice thing about implementing script triggers like this is that the user gets feedback on what’s right or wrong when entering data. One approach is from a preventative perspective, while the other warns the user when something needs to be fixed. It’s these types of techniques that can really make a solution clean, elegant, and user-friendly.