Popup Pickers

Back in 2009, David Graham released a demo called Spotlight Filter that caused a minor revolution in the FM development world: a) it neatly solved a problem that many developers routinely face, and b) it was an early and convincing implementation of FileMaker script triggers.

The problem it solved was, “How can I provide my users with a lightning-quick, keyboard-driven popup-window to pick from a set of values, for example, to add a customer or a product to an invoice?”

Historically I’ve tended to be skeptical of “pseudo dialogs” (using a FileMaker window to simulate a modal dialog) because many of my clients are on Windows, and there is an annoying windowing behavior that can arise under certain circumstances: if your background window is maximized, it will not stay maximized if you attempt to display another window in front of it in a “windowed” state. However, as screen resolutions have increased over the years, this has become less of a concern than it formerly was.

But note: if you deploy on the Windows platform and your design methodology relies on the active window being maximized, then this technique is not for you.

At any rate, I decided to use Spotlight Filter on a project recently, and made some changes which I found useful, and thought perhaps others would as well. I discussed these changes with David Graham, and he offered some observations and suggestions, which I  incorporated. This article’s demo file, Popup Pickers, is offered with his permission.

But first a bit of background. Geoff Coffey’s informative piece about Spotlight Filter is required reading in my opinion. There’s no point in rehashing what Geoff has already explained concisely, so I will proceed on the assumption that the reader is familiar with it.

Next, I will risk stating the obvious: the purpose of a “picker” is to allow the user to search a set of records by typing in one or more search terms; these terms can be fragmentary (“jo sm”) or complete (“john smith”), and the order of the terms is not important. When the desired record has been located and then selected, the primary key for that record is inserted into a foreign key field in the appropriate target table.

So, what changes will you find in the current demo?

1. Includes a primitive invoicing system
2. Something actually happens when you “pick” a record
3. The picker auto-centers in front of the source window
4. Modal behavior
5. Completely keyboard driven
6. Uses scripted find + list view, rather than relationship + portal
7. Uses some new-in-FM 11 features

Let’s look at at each of these in closer detail.

1. Includes a primitive invoicing system

(See next comment.)

2. Something actually happens when you “pick” a record

The beauty of Dave’s original demo is its simplicity: a couple layouts, three scripts, just the essentials, and make of it what you will. But I figured a simulated real-world implementation wasn’t such a bad thing either. In the new demo, you can pick both customers and products.

3. The picker auto-centers in front of the source window

This is useful code to have, if it’s not already part of your FM tool kit. Note that we don’t want the picker to center in the middle of the screen, but relative to the background window.

I could have used “adjust window (resize to fit)” rather than explicitly coding the $dialogWidth and $dialogHeight variables, but the dialog draws more cleanly on the screen this way. I actually do perform an “adjust window” a bit later, but that’s after the popup picker has already been centered.

4. Modal behavior

A modal dialog is one that stays in the foreground until dismissed; while the modal dialog is on screen, other windows cannot be interacted with. It’s a not-very-subtle form of user coercion, which facilitates the enforcement of business logic.

5. Completely keyboard driven

a) Esc dismisses the dialog (without picking anything)
b) Up and Down arrow keys navigate between matching records
c) Return or Enter selects the current item

And of course search results update in real time as you type; this isn’t a change — it was the whole point of Dave’s original demo.

6. Uses scripted find + list view, rather than relationship + portal

By using scripted finds, we give the user a lot more flexibility re: the terms they use and the order they type them in. We also dispense with relationships, custom functions and the indexing overhead of the exploded foreign key in the original demo. If the user is familiar with FileMaker search operators, they are welcome to use them, e.g.,

For products containing the word “chard”, but not “chardonnay”, search on “=chard”

For products beginning with “white”, search on “==white*”

7. Uses some new-in-FM 11 features

a) Merge Variables

b) Variables in scripted find requests

Finally, a few words about the script triggers. There are three picker layouts in the demo… all three of them have the same OnLayoutKeystroke trigger: “pp: process keystroke?” I used OnLayoutKeystroke rather than OnObjectKeystroke, because I want keystrokes to be processed whether or not the user’s cursor is in the search field.

The search field also has an OnObjectModify trigger, which varies depending on the layout.

As with all of my demos, this one is a starting point, not the last word on the subject. I invite you to pull it apart, and change it to suit your needs. And naturally if you see room for improvement, I hope you’ll post a comment here.