As FileMaker developers, we often use a bit of interface trickery to make things appear as just regular old fields on a regular old layout, when in fact portals, filtered or not, may be hidden on the layout. Well when we use hidden “stuff,” we sometimes confuse the user when it doesn’t behave like regular “stuff.” In this blog entry and video, I’ll walk you through a scenario where portals and script triggers can work together to make for a seamless experience.
In this example, I have an item table. On the layout there is a portal, or a related table, where the user can enter different numbers representing PMS colors. To ensure good data modeling, I used a separate table and not just 8 fields called “Color_1” through “Color_8.”
Now imagine this scenario:
The user enters a new item. She types 108 in the first color field (really a related field), then types 2100 in the second color field, and lastly 301 in the third color field. She then realizes that 2100 is not for this item and deletes the value from the field. Structurally, this item record has 3 related records, even though there are only 2 values in the PMS color field. Now the user wonders, “Why is there a gap between color 1 and color 3?” and the developer is stuck cleaning up the data or error trapping for these “empty” records.
To solve the issue, I’ve created a simple script that uses the OnObjectExit script trigger. When the user exits any of the PMS color fields, the script checks to see if the color field for that related record is empty. If it is not empty, then nothing happens. If it is empty, the script deletes that portal row. No “empty” fields, no “empty” related records!
Check out the video and let me know what you think.
Great idea, Martha! That’s what I love most about script triggers. When they first came out, people were doing really big things with them, but the true magic is in all the tiny things they can do to make a seamless interface.
Nice idea! Have you tried it with OnObjectValidate? That way the script will only fire when you exit the field and it’s been modified, rather than every exit.
Great example! I agree with Paul – making the user interface behave more naturally to the user is one of the best ways to use script triggers.
Similarly, I have just used script triggers to make checkboxes work more naturally in FileMaker Go. Going to share that soon…
Paul – I’m all for the seamless interface!
Tom – Great point! I didn’t consider that and it is a better approach. Thanks!
Honza – Looking forward to your example of “natural” checkboxes.
Thanks for all of the feedback, gentleman.