Teaching Pickers to be Patient
FileMaker is a very responsive application – you ask it to do something and it responds pretty quickly. But sometimes, we want FileMaker to be more patient and wait until we’re done before it does something. In effect, we want FileMaker to practice a bit of patience.
We’re going to talk about pickers today, and specifically, how to use an OnTimer script step to make FileMaker practice a bit of patience while we’re picking. What’s a picker you ask? Well, in FileMaker-land, it’s sort of a fancy pop-up menu. We’ve all seen systems where you have a field – ‘Country’ would be a common example – where you’re presented with a pop-up menu of choices that you need to scroll, scroll, and scroll through in your effort to find the item you want.
Wouldn’t it be nice if you could search that list instead?
That’s what a picker lets you do. It gives you a simple interface – usually, a search field is used to filter the list, so you can narrow a list of 500 types of [whatever you’re looking for] down to just a few possibilities. This can make it much easier for a user to select the correct data to put into the field, especially when the list of possible choices is large or will grow over time.
Picker Basics
We’ve been creating pickers in FileMaker for a while, and there are a number of different ways to implement them. Here’s a basic example of what one looks like:
Screenshot 01
Most pickers share a few common elements:
- a field into which you will type your filtering criteria
- a ‘search’ button that executes the search
- a ‘clear all’ button of some kind, that will clear the filtering criteria
- a list of items that we’re searching through using our filter
In its simplest form, clicking on an item in the list will select it and enter that data into the field that’s attached to the picker. For example, by clicking on ‘Mark Hamill’ above, the string ‘Mark Hamill’ will be selected and put into the target field, i.e., the field that we were aiming to fill when we invoked the picker in the first place.
Finding the Droids You’re Looking For
One thing that I find clunky in the interface above is the ‘Search’ button. Why should the user have to click another button in order to start filtering? The system should be able to start narrowing the results as we type.
That said, while we DO want our picker to use some sort of “Jedi mind trick” to perform the search as we’re typing, we DON’T want it to do that after every keystroke. We want FileMaker to practice patience, and to only execute the search when we pause for about half a second or so.
To do this, we’re going to use OnTimer scripts as a sort of ‘snooze button’ for determining when to perform our search.
I’ve used a copy of the Events Management template that comes with FileMaker to illustrate this example. I created a new event called “St. Louis Comic-Con” to which all (yes, all!) of the Star Wars actors are coming, of course. As I hear back from them, I want to be able to add them to the event as a Contributor.
Right now, the field that I’d use to enter their name is a simple drop-down list:
Screenshot 02
Given the size of the Star Wars universe, and the number of actors involved (which is huge and only getting more so over time), I want to convert that drop-down list into a picker.
To create my picker I’ve done the following:
- Created a new layout based on the ‘Contacts’ (aka ‘Actors’) table
- Added a master-detail portal on that layout, which will let me search in the context of the items I’m searching and thus narrow down (or expand) that list of records
- Created a new global field in that table called ‘gSearch’ and added that field to the layout
- Added a button that will clear the search field
This is what my new layout looks like in layout mode:
Screenshot 03
Now we’ll build the scripts that will orchestrate and control how our picker behaves. Again, there are a variety of ways to do this. For example, you can build a single script that does everything depending on what parameter you pass it, but in the interest of simplicity and clarity, I’ve broken out each task into its own script.
Contact Picker: Open
This script simply opens up a card window to the new layout and calls a script that clears the search criteria:
Screenshot 04
Contact Picker: Clear
This script clears the search field and resets the found set and sort conditions to their default state:
Screenshot 05
Contact Picker: Search
Screenshot 06
This script is where we will “feel the force”. This script simply shows all records if ‘gSearch’ is empty when the script is executed, or it uses the contents of ‘gSearch’ to perform a find on the ‘Contact Name’ field. Since we’re using a master-detail portal, finds and sorts act on that portal just like they would in a normal list view.
The only unusual part of our script is line 6, where we call a blank ‘Install OnTimer Script’ script step. This will halt any or all OnTimer Scripts that have already been installed and which are currently running on this card window. Why do we need to do that? I’m glad you asked because this is where things get a bit ‘mind-bendy’.
The idea here is to execute the find while the user is still typing, right? Thinking about that, the first option that comes to mind is to attach the ‘Contact Picker: Search’ script to the OnObjectKeystroke script trigger for the ‘gSearch’ field. If we do this, the script will run every time FileMaker detects an individual keystroke. Our work here is done, yes?
Actually, no. The problems with this approach include performance and usability. We’ve found that having the search script execute every time you type any single keystroke can make entering data into the search field awkward and slow, especially for hosted files. Instead of feeling responsive, it feels like the system is constantly trying to play catchup with the person typing.
How do we solve this problem? How do we introduce a slight pause so that the script only executes when the user slows down typing for a bit? How do we teach the script, like a young Jedi, to be patient?
The answer is using an OnTimer Script in combination with the OnObjectKeystroke script trigger.
Contact Picker: Start OnTimer
To understand how this Jedi magic works, you have to understand how OnTimer Scripts work. Every time you call an OnTimer Script, it cancels the last one that was installed on that window and installs the new one. Below we’ve created a script called ‘Contact Picker: Start OnTimer’ that will run the ‘Contact Picker: Search’ script every 0.5 seconds:
Screenshot 07
… and we’ll trigger this new script by assigning an OnObjectKeystroke script trigger to the ‘gSearch’ field:
Screenshot 08
Using the setup pictured above, when we type the first character in the search field the OnTimer will be installed and the timer will start – a 0.5-second countdown begins – but it won’t execute the search until that 0.5 seconds have gone by uninterrupted. If you type the next keystroke in less than 0.5 seconds, it calls this same script again, canceling the last OnTimer Script that was running, and basically resetting the countdown clock back to 0.5 seconds.
It’s like hitting the snooze button on your alarm before the alarm goes off, over and over again, until you ‘fall asleep at the keyboard’ long enough for the countdown to get to 0 and the search script to actually get the chance to execute.
Wrapping Things Up
I’ve added in a couple of other scripts to my example file ( Teaching Pickers Patience - Event Management Copy.fmp12 ) to complete the round trip to and from the Contributor list so that it will capture whatever the user selects in the picker and set it into the appropriate field back in the list, but the key takeaway technique here is all about the behavior of the OnTimer Script and how we were able to leverage it using the OnObjectKeystroke trigger.
And that, my young Padawan, is how you teach FileMaker to practice a bit of patience – adding a ‘snooze button’ via the OnObjectKeystroke trigger so that your search doesn’t execute with every keystroke, but only when your user stops typing for a brief pause.
May the force be with you – and your FileMaker solution!
**Thanks to Stu Dietz here at Skeleton Key for walking me through his version of this technique and brainstorming about how to best present it in this post. Thanks also to the unknown ‘FileMaker developer out there’ who first came up with this useful technique!
