Here are all the components of this process and how they fit together:

AddOrRemoveFromList(list, value) – The custom function that will maintain the values in the list for you.

$$selectedItems – The global variable that stores the list I want to operate against.

Selected Item – The actual record that you are adding to the list.

First I’d like to explain the custom function.  Basically, that function checks a list that you the value you pass in.  If the function finds that value, it removes the value and returns the new list sans value.  If it doesn’t find the value, it returns to you the list with the value appended to the end of it.  Here is the what AddOrRemoveFromList(value, theList) contains:

let(

[newList = Substitute(¶ & theList & ¶, ¶ & value & ¶, ¶)];

if( PatternCount( ¶ & theList & ¶; ¶ & value & ¶) = 1 ; Middle(newList, 2, length(newList) – 2); theList & if(not isempty(theList); ¶) & value)

)

The reason for all those extra ¶’s is for encapsulation and searching.  When you think about what a list actually is, it turns into this:  apple¶orange¶pear¶applejuice.  If you want to search that list for apple right now you would be editing both the values apple and applejuice.  To get around that we put an extra ¶ before the first entry in the list and after the last entry so our list now looks like ¶apple¶orange¶pear¶applejuice¶.  So, if we now search for ¶apple¶ we would only be working with the actual apple value.  To get the correct list format returned after that you just need to use the middle function to strip the first and last ¶ from the list.

So, we now have a custom function that will handle adding and removing values from a list.  The only thing we have to do to make a selection is to say where we want to store the list.  Using a global variable has the advantage of being easily accessible and being completely separated from your data structure, so you don’t need any additional fields or records to keep track of what the user wants selected.  So, if you choose to use a global variable, the only step you need to take is to set the variable $$selectedItems using the custom function.  Here’s what that step looks like:

If you are unformiliar with our parameter passing system, please take a look at this.  So, we now have the selected items being added to the desired list automatically.  So, let’s let the user see what they’ve selected.  Using conditional formatting we’ll just apply that same list checking we used in the custom function.  The formula should be:

PatternCount( ¶ & $$selectedItems & ¶; ¶ & item & ¶) = 1

“item” in the above example should be whatever you passed into the list.  No

Note: We’ve never done this before, but the idea, scripts, and sample file for this technique come directly from FileMaker luminary and Six Fried Rice reader David Graham of Bit Tailor. We’re publishing it here (with David’s permission) because it is an excellent example of Script Triggers solving an age-old problem in an elegant way.

There are as many ways to filter lists in FileMaker as there are developers implementing it. The beauty of this technique is that it doesn’t matter if you prefer exploded keys and filtered portals, aggregate text fields and a find, or (my personal favorite) scripted multi-request finds. Whatever you want, when it is fast, clean filtering you’re after, it is always better if the results appear as you type. This sort of thing was essentially impossible with FileMaker 9. Once a user started entering data in a field, you were hands-off until they finished.

Some people dreamed up horrifying solutions with looping scripts and all manner of wackiness. These techniques, in my opinion, never worked well. Consequently, we were always resigned to the “press Enter when you’re done” model. But when the results appear as you type, the user gets immediate feedback, only needs to go as far as necessary to get the result she wants, and doesn’t have to click back into the field to correct or make a change. So it is clearly a better model. See for yourself:

David’s technique relies on the handy OnObjectModify trigger on the filter field to kick off a script every time the field changes. This includes:

• When you add a single letter to the field by typing a key.
• When you remove something by pressing Delete or Backspace.
• When you cut text form the field or paste it in.

You may be tempted to use the OnObjectKeystroke trigger for something like this, but OnObjectModify gets you more bang for the buck: It handles cut and paste, and doesn’t require all the complexity of keystroke triggers.

The Code

I’ll let you explore David’s sample file for the full scoop, but the core of his technique can be found in two places. First, he uses an exploded key filtering technique, which I won’t cover her, except to say that the idea is to process some text data and produce a multi-line key that includes partial match values. In other words, if the value is “Test” then the key would match “T”, “Te”, “Tes” and “Test.” In this way, you can type all-or-part of the value and see the results. Look at David’s ExplodeToMultikey custom function to see how he accomplishes this.

If you prefer, you can use scripted finds and a list view layout to do your filtering instead.

But the interesting part is this very simple trigger script:

Set Variable [$currentObject; Get ( ActiveLayoutObjectName )]
Commit Records/Requests []
Go to Object [ $currentObject ]
Set Selection [ Start: Length (Get(ActiveFieldContents)) + 1]

That’s it. This script really just does two things:

1. It commits the record, causing anything you’ve typed in the filter field to take effect.
2. It returns you to the field, so if you type again, your keystrokes will go right on the end of the field.

In this way, as you type, your changes reflect immediately. Very cool.

Note: If you were using finds instead of exploded keys, you would add a a few more steps to your script to switch to Find mode, build a find request or two, and then perform the find.

You can download the working file right here.

Thanks to David for the great technique!