Quick Find: the forgotten feature

Released with FileMaker 11, more than 8 years ago in 2010, Quick Find is probably one of the most underestimated features in FileMaker.

For some reason, there wasn’t even much emphasis in the product marketing when it was released. Platform evengelists would mention it as a ‘Google-like search engine within FileMaker’, product documentation said ‘search in all fields of current layout’, but it was never said clearly how powerful this feature is.

And it is extremely powerful.

First of all, let’s sum up the various implementations of Quick Find in the product.

• Quick Find search field in the toolbar. This is probably the first thing one would mention while thinking about Quick Find: the Toolbar includes a search field where the user can type criteria and trigger the find hitting Enter. There’s already something to mention about it: this search field is available only in browse mode. It would, I think, make perfect sense to have it also in find mode. It is common to see users first think they want to find something and therefore switch to Find mode, then only to realise they could use Quick Find. They have then to go back to browse mode before they can use it, which is a bit odd and might be a reason why Quick Find isn’t as seamless as it could.
• Perform Quick Find script step. Does the same as hitting enter while the search field is active, except the criteria can be specified. It is therefore trivial to build your own Quick Find interface, and it works in Find mode too!
• In layout mode, Quick Find badges at the bottom right of layout objects. The Magnifying glass can be green or orange, depending on how fast FileMaker presumes the find will be. Basically, it’s green for indexed or indexable fields of current table, and orange for unindexed or related fields. Note that I wrote ‘layout object’ and not field: a text object including merge fields can be included in Quick Find index. Other types of objects can’t, even if they include layout level calculations (button bars, web viewers, tab panels) or merge fields (buttons).
• In the inspector behaviour panel, a checkbox labeled ‘Include field for Quick Find’ is active when a field or a text object containing merge fields is active. Very unfortunately, FileMaker has decided from the beginning that every new field object added to the layout would be included by default in Quick Find. This is, from my point of view, the main reason why this feature is underestimated and, I would say, rather dangerous. Because the first Quick Find performed on a layout will trigger the indexing of all indexable fields included in the Quick Find, having all these fields included will cause a huge, unnecessary index. Quick Find is powerful because you can select which fields are included, but having them selected by default weakens the feature itself: who would like to search in a phone number or in a boolean in the context of a Quick Find? It ends up in returning irrelevant data, and causes the index to grow incredibly.
• In the layout format dialog, a checkbox labeled ‘Enable Quick Find’, checked by default allows to disable Quick Find on the layout. The badges mentioned above are then greyed out, and the Quick Find search field is disabled in browse mode. Next to this checkbox, a button says ‘Reset Quick Find’, which basically will include all fields for Quick Find, because this is the default setting)
• Finally, still in layout mode, in the View/Show menu, you can enable or disable the layout badges. By default they are disabled, which is a pity because this is your only chance to avoid having too many fields included in the Quick Find. These show options have to be adjusted before you upload the file on a server, otherwise you’ll have to set them again for every session.

Tips and tricks

Here are a few things you should know before we come to the core of this blog post

• Quick Find doesn’t support operators like *, …, //, =, ==, etc.
• There is no ‘constrain found set’ or ‘omit record’ equivalents. You can’t use Quick Find to fine tune a previously found set of records.
• Error trapping is different for Quick Find than with a simple Perform Find. Namely, if you get a 401 error (no records found), the previous found set is preserved, whereas with Perform Find you end up with 0 (zero) record. So if you’re used to trapping the error with Get ( FoundCount ) = 0 instead of Get ( LastError ) = 401 , you’ll have to adapt your scripts for Quick Find.
• Fields on the right hand side of the layout and therefore not visible in form and list views can be included in Quick Find. A very clear and easy way to manage fields that are included in Quick Find is to select all objects from the left (visible) part of the layout and uncheck the ‘Include field for Quick Find’ box, and on the right part, add a Quick Find zone with only the fields you want to search, and of course include them in Quick Find.
• If your solution hides the toolbar completely and you’re sure the users won’t use the toolbar Quick Find search field, you can push this logic a bit further and disable Quick Find on the layout and create dedicated layouts with only the fields you want to perform Quick Find on. This way you’re sure than even if you add some fields to your main layout, they won’t be included in Quick Find, because it’s disabled there.

Now the big thing

But wait, didn’t I write that the power of Quick Find was underestimated? so where’s this power I was talking about?

Well, it’s simply the way Quick Find does search. Because we’ve had the classic Find mode and Perform Find script step for so long, many overlooked the Quick Find feature thinking it was just like a find, but on many fields at a time.

Say I have a Contact table with firstName, lastName, occupation, city, of which firstName is the only field not included in the Quick Find. And I’m looking for a plumber in Cincinatti. What you would do with the classic find is

• go to find mode
• enter ‘plumber’ in the occupation field
• enter ‘Cincinnati’ in the city field
• hit enter to perform the find

In the old days, if one wanted to propose a ‘Google-like’ search (even before we’d heard of Google), he could add an indexed calculation field to the table like

city & " " & lastName & " " & occupation

and enter ‘plumber Cincinatti’ in find mode, and that’s because FileMaker considers individual words in the same field as criteria with an AND operator.

But with Quick Find, you don’t have to create this field because what Quick Find does is NOT

• go to find mode
• enter ‘plumber cincinatti’ in lastName
• new request (OR)
• enter ‘plumber cincinatti’ in occupation
• new request (OR)
• enter ‘plumber cincinatti’ in city
• perform find

If it was this, then no records would be found because none of the fields contains the 2 words.

What Quick Find does just cannot be done with Perform Find. It takes each word and does all possible combinations. So with ‘plumber Cincinatti’, it takes the first word (plumber) and finds all records where one of the 3 fields contains ‘plumber’ and then among those, it finds all records where one of the 3 fields contains ‘Cincinatti’. This explanation has nothing to do with HOW it does it (the process is probably very different from this). I’m only trying to explain WHAT it does.

But the magic doesn’t stop here. This combinatory search also works with related records! So you can for instance search for ‘plumber Cincinatti approved supplier’ where ‘approved supplier’ is a value to be found in the related company table. The only thing you have to do is insert that field on the layout and make sure it’s included in the Quick Find.

In the attached sample file, you will see a search engine that gets results from multiple tables. In the old days, you would have had to draw complex relationships with a bunch of ≤ and ≥ criteria, calculated fields and all. Look now how simple it is to perform Quick Finds, get the results to a global field and display the result with a simple relationship.

I hope you learned something with this blog post. Please feel free to drop a line here under in the comments.