This is the second video from the first annual FileMaker Feud at the 2011 FileMaker Developer Conference. (Here is Part 1). In this video, Laura Betz and Lee Lukehart take on Perren Smith and Mark Richman to determine who advances to the final round. The crowd was warmed up so there is plenty of friendly banter with the host Dave Weisiger.
What happens when you survey 100 FileMaker developers? The first-ever FileMaker Feud, hosted by MightyData, at the 2011 FileMaker Developer Conference. Two teams competed for the title of FileMaker Feud Champion (and cool prizes like the iPad 2 and MightyCoach) by choosing the most popular answer to questions about layouts, calculations and scripts. In this video (first of three), learn who is the Northern-most FileMaker developer, why Martha thinks FileMaker is “pretty”, and which team advances to the second round.
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.
Ever since sub-summary parts started working in Browse mode, developers have been using them to enhance list layouts. The catch? Find mode.
If you place a field in a sub-summary part, the user is unable to enter the field in Find mode since it is not in the body part. So while the technique adds functionality in one mode, it removes it from another.
Watch this short video and learn how conditional formatting and field behavior can solve the issue. With “hidden” fields and “no entry” in Browse mode, you preserve the beauty of Browse mode and keep the functionality of Find mode.