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.