Real-Time QuickFind
by: David Thorp
R…
Re…
Rem…
Reme…
Remem…
Rememb…
Remembe…
Remember…
…what life was like before instant search on the web became the norm? We had to actually type out whole words and phrases, hit the pesky “return” key and THEN look at the results. Then maybe type in more words and phrases and search again if the results weren’t quite to our liking.
Just like us, our users have come to take instant-search for granted. Search results autocomplete as you type. That’s just how computers work now. Except, of course, in the hundreds of applications that don’t intrinsically support an instant search feature, including, sadly, native FileMaker Pro.
In the grand scheme of things, FileMaker Pro’s Find Mode is pretty amazing. This native functionality allows for extremely powerful granularity in the construction of both specific and more open-ended queries. Custom development can add to the simplicity and speed of producing a found set of records using Find Mode.
But despite all of this, the web has given most of us a different set of expectations when it comes to intelligent and efficient searching. The responsiveness of your favorite search engine – or any similar search fields found within a myriad of modern web, desktop and mobile apps – can make the task of performing a find in FileMaker Pro seem somewhat old school. Even FileMaker Pro’s built-in Quick Find feature, which returns the results of a query of multiple fields on a layout at once, stops short of providing the kind of instant gratification of seeing every possible result as you type. There are plenty of cases where the interface, the application, or the specific problem points to a “Search” box that users will use and want to see instant results.
But instant searches are about more than instant gratification. For the most active users of a solution, the time spent searching for records and sets of records adds up fast. Any amount of time saved is more than just a welcome feature. In many cases, the immediate feedback of instant search is expected.
So the challenge we tackle here is to provide results which are quicker – dare we say in “real time” – than successive Quick Finds, and provide users the experience of knowing the answer to their questions before they finish asking them. There are a few ways to do this, as we’ll see, and a few challenges with implementation that require a bit of extra attention. We want to find relevant records and return results instantly, as users type, with the fewest possible keystrokes and no unnecessary delays.
That “no unnecessary delays” is the fun bit…
FileMaker Pro’s native QuickFind feature is a script step (Perform QuickFind) that takes the contents of a given field and searches for its contents in whatever fields are set to allow it, on the current layout. But how to get it to run…
Option 1. Put a button next to the field. Click the button. Performs the Find. Ok. But we can do better.
Option 2. Add an OnObjectExit script trigger to the field. Type your criteria. Tab out of the field. Script is triggered and performs the find. But what about those “instant results” we were talking about?
Option 3. Add an OnObjectModify script trigger to the field. Now we’re getting our “instant results”. Every keystroke that modifies the field triggers the script and performs the find. But…
The problem here? What if the find takes a while, for any reason: unindexed fields being searched, large numbers of records, deployment over WAN, etc. That’s going to make. every. keystroke. pretty. tedious.
Check out the file to see our solution. 🙂
**This article is provided for free and as-is, use, enjoy, learn, and experiment at your own risk – but have fun! eXcelisys does not offer any free support or free assistance with any of the contents of this blog post. If you would like help or assistance, please consider retaining eXcelisys’ consulting & development services.
About eXcelisys, Inc.: Founded in 2001, eXcelisys (www.excelisys.com)is an FBA Platinum Partner and FileMaker Certified developer organization. eXcelisys specializes in designing, developing, customizing, supporting, consulting, migrating, upgrading, fixing, and integrating of database solutions for Desktop, Mobile, and Web. Our core technology competencies are FileMaker Pro, FileMaker Go, and MySQL for database frameworks, along with FileMaker WebDirect, WordPress, MySQL, PHP, CodeIgniter, PostgreSQL, Joomla, Drupal, Magento, CSS, HTML5, and Javascript for web sites and web applications. Aside from providing eXcellent customer service, our goals are to use these technologies to intuitively automate your organization’s data solution needs seamlessly and flawlessly across the web, mobile, and desktop platforms. Contact eXcelisys today for a free estimate and consultation about your business software automation needs @ 866-592-9235.
eXcelisys, Inc. is an independent entity and this web site/information/blog post has not been authorized, sponsored, or otherwise affiliated with FileMaker, Inc. FileMaker is a trademark of FileMaker, Inc., registered in the U.S. and other countries.
Hi,
interesting, but in your example file, finds are atrociously slow…
Yes it’s on purpose (???!!!???)
“Finds are intentionally slow for demo purposes.”
But I can’t see how to accelerate it. What’s the point of a demo which is slow ?
Hi “Me”.
Great questions. You’ve essentially asked two questions:
1. How to accelerate it?
The nature of the Perform Quickfind script step is that it performs a find on all the fields that are actually on the layout (and that are set to be included for Quickfind in the Inspector).
If you go into Manage Database in the demo file, and look at the Fields list for the Data table, you’ll see six fields: three standard, indexable text fields, and three unstored calculation fields.
In the demo file as it is, the fields showing on the layout are the three unstored calculation fields. By using those fields on the layout it forces the Perform Quickfind script step to perform its find on those fields. That’s where I’m artificially slowing it down.
To accelerate it (or undo that artificial slow down), simply change those three fields on the layout to the corresponding stored text fields and then it will perform the Quickfind on those fields instead. Once you do that, the unstored calc fields aren’t needed and can be deleted.
2. Why did I intentionally slow it down?
If you apply this technique in your solution and your solution is on a server somewhere else on the internet then you’re dealing with the relatively slow speed of the internet, compared to if it was on a local network. Or even on a local network, if the data you’re searching on is not able to be stored and indexed – instead it has to rely on unstored calculations – then you have another situation where things are slow not by choice.
I slowed it down artificially and intentionally, simply to illustrate that this technique produces good performance even in situations where things are slow not by choice. I did that by forcing the Quickfind to perform on unstored calculated versions of the data instead of the stored, indexed data. Undo that as described above.
——
All that said, then there’s the question of why you’re finding the finds to be atrociously slow, when everywhere I’ve tried this file it’s not. One explanation I could possibly give is as follows:
On my iMac the file, as is, produces results within two seconds of when I stop typing in the QuickFind field. Mine’s a relatively new iMac. On an older or otherwise slower computer maybe that two seconds is four seconds instead, just for argument’s sake.
Without this technique, but while still using an OnObjectModify to get feedback as you type, you’d experience that four second delay AFTER EVERY KEYSTROKE. If your search involves entering the name “James” that’s five keystrokes and five lots of four seconds, or 20 seconds. Perhaps this is what you’re experiencing?
The point of this technique is to stop it from performing that four second find after every keystroke and instead only perform it after you stop or pause typing for, in this case, at least 0.5 seconds – that is, the duration of the Pause/Resume Script step in line 21 of the script. As long as you type the word “James” such that there’s no more than 0.5 seconds between each keystroke, then it will perform the find only once, at the end – a four second delay instead of 20 seconds. But if your typing speed is such that there’s more than 0.5 seconds between each of your keystrokes then you’ll experience that four second delay as it performs the find after every keystroke, thus defeating the purpose of the technique.
The good news is, you can change the 0.5 seconds in line 21 to something larger – depending on your typing speed, let’s say one second per keystroke. Then you can type in the field, and it will only perform the actual find after you stop typing for more than that one second. If that’s still not a long enough delay between your keystrokes, increase that Pause/Resume Script step duration further.
Hope that helps!
David.
Is there a way to show results that contain the search string anywhere in the field? E.g. the field says “Charlie” and if I enter the search string “rlie” it will show me “Charlie”?
Hi Cameron,
Great question. Ok a few points…
1. By default, in all FileMaker’s methods of finding strings, FileMaker finds strings that match the beginning of a word.
2. In normal Find Mode in FileMaker you can use various operators to find other options, for example the asterisk operator can substitute for any number of other characters, so in your example a find (in normal Find Mode) for “*rlie” would find “Charlie”. ( You can see more details on those options here: https://help.claris.com/en/pro-help/content/finding-text.html?Highlight=finding%20text )
3. On the other hand, FileMaker’s Quick Find feature doesn’t support any of those operators (with one exception that doesn’t help us here. See the first of the “Notes” on this page: https://help.claris.com/en/pro-help/content/perform-quick-find.html?Highlight=performing%20quick%20find )
And this tip uses FileMaker’s Quick Find feature for actually performing the find.
So in short, what you are asking for isn’t supported by FileMaker’s Quick Find feature. The solution is to implement something more elaborate using FileMaker’s normal Find. To do so would be more than we can explain in a basic blog post… my suggestion and recommendation would be, for you to hire us!
Please feel free to contact one of our account managers here:
https://excelisys.com/team/contact-us/
I hope that helps!
David.
David,
I really like this Real-Time QuickFind, but unfortunately it does not work properly in Web Direct. After typing each character to cursor jumps back to the beginning in front of the character(s) typed. I have tried to figure this out, but so far have not. Can it be fixed to work with Web Direct? Thank you
WebDirect doesn’t allow us to get the selection details which is a significant part of the scripting in this tip file. Since it’s not supported, your only option would be to simply ignore it and force the selection to be at the end of the field regardless of where the cursor started out when the script was triggered. With that restriction, the script could then become only two steps:
1. Perform Quick Find [Globals::quickfind]2. Set Selection [Globals::quickfind; Start Position: Length(Globals::quickfind)+1]
The delay that occurs when triggering scripts in WebDirect makes this approach feel cumbersome even under the best circumstances but that’s what we’re stuck with at the moment.
David,
I am using a master detail layout with the master list portal on the left and the detail page on the right. I copied a formatted Search entry field I like from another db and attached the global field quick find field from the globals table and the search is not working. Does the quickfind need to be on it’s own layout with the data table as a portal below it? Or do I need to use the unstored call fields first name, last name, and company to get it to work?