Last week, I had an amazing time traveling down the West Coast, speaking to enthusiastic and excited user groups in Seattle, Portland, San Francisco, Santa Clara, and Las Vegas. Topics included Snapshot Link, Quick Find, Filtered Portals, Script Triggers, and Charting.
I’d like to send a huge thanks to all of my hosts and everyone who attended the meetings. One of the things I promised each group was access to the sample files I showed. So I’d like to share that with a bigger audience and put them right here on the blog.
Based on my sample files, there are three main topics I’ll cover – Snapshot Link, Filtered Portals, and Script Triggers. My goal for each demo file was not only to show ways to incorporate these techniques into existing solutions but also to think of these techniques outside of the box.
Snapshot Link
In this sample file, there are two uses of Snapshot Link:
- Launch file
- Bookmarking when closing
For the launch file, open up the solution. Once you’re at the opening screen with the “About” and “Demo” buttons, create a Snapshot Link and place it on your desktop. As long as the file doesn’t move, the Snapshot Link on the desktop can serve as your launch file. Nice and simple!
For the bookmarking, there is a script written called “On Close” that runs when the file closes (via File > File Options…). The script shows a dialog, asking the user if the place should be saved. If the user agrees, the script saves a Snapshot Link to the desktop, that the user can click when ready to start off where the database was last left.
Filtered Portal
In these two sample files, there are two uses of the Filtered Portal:
- New approach to tab controls
- Report management
It’s common to create a solution with tab controls, but what if you wanted to change the look? The layout “Sample Menu | Tab no Hierarchy” shows you the way that a filtered portal can enhance the user experience and be used to control the tabs. This technique takes a combination of the following:
- Hidden Tab Control (Fixed Width of tab = 0) where each tab has an object name
- The table “Tab” that stores the tab display name, the menu group, the sort order, and the object name that each menu corresponds to.
- The script “SwitchTabs” that takes the user to the correct object based on the object name stored in the Tab table.
The layout “Sample Menu | Tab” takes the technique to the next level, allowing a hierarchy of parent and child. The added tools to make this technique work include:
- A field in the table “Tab” called “Belongs To” that ties each record to a parent record
- A global variable that contains the “Belongs To” value, for the filtered portal
The other sample file for filtered portals shows the way to use a filtered portal with global fields. Not only is the user interface clean, but the user has control over what reports they can see. You’ll notice the “Not isEmpty( )” in the Filtered Portal calculation. One of the things I’ve learned over time is that if the user selects nothing in a filter, he or she wants to see everything. This is counterintuitive from a logical perspective, but an accepted (and expected!) behavior. Filtered portals require quite a bit of testing, trial, and error.
Script Triggers
While Script Triggers were first introduced in FileMaker 10, the newest version brought a few new triggers. In these two sample files, there are a number of uses for Script Triggers:
- OnViewChange: Changing views (read: layouts) with the toolbar
- OnObjectValidate: Providing feedback for erroneous data
- OnObjectKeystroke: Limiting keystrokes and characters
In the first sample file, the script “Change in Views” is being triggered by OnView Change. If the user clicks on the “list view” from the toolbar, the script is executed, taking the user to a layout with the same data, but properly created for a list view. The same applies for table and form view. The important part of the technique is the consistency in the layout names. All of my layouts end with the word that defines the layout view.
In the second sample file, there are three examples:
- OnObjectValidate – Allowing a range based on the script parameter (Example: 1 to 10)
- OnObjectKeystroke – Not allowing the user to type anything but positive numbers (including the decimal point)
- OnObjectKeystroke – Not allowing the user to type anything but numbers (including the dash for negative numbers)
There is also an example involving the dropdown. One of the things my user discovered was the ability to type into the field if the dropdown wasn’t showing. By using OnObjectKeystroke, the user is limited as to what keystrokes will actually occur. However, it is important to note that certain keystrokes are allowed, even though they don’t produce a character. These keys include: backspace, return, escape, and arrow keys. Removing these from the user’s capabilities would leave the user feeling handicapped, potentially marring the user interface, instead of improving it.
All of these sample files are just some techniques I’ve used in real solutions I’ve built for customers. It was not only a fun way to play with existing techniques but a great way to implement a friendly user interface. Feel free to implement them, break them, and make them better! I’d love to hear how you include them in your work or ways that you’ve taken the techniques down a different route.
