A few months ago, I delivered a webinar on advanced scripting and calculations. Along with the video demonstrations, I made available the FileMaker file for download. Dennis watched the webinar, downloaded the file, and asked a most reasonable question:
Thanks for your example of a Quick Find. I am having trouble understanding the find definitions in the Quick Search script [shown below]. I understand that the 401 error traps the situation where none of the search argument finds a hit in the table, but I dont understand what the omit statements are supposed to do. Could you please elaborate? Thanks!
Yeah, that one does require some explanation…
Here is the script in question:
Allow User Abort [ Off ]
Set Error Capture [ On ]
Commit Records/Requests [ ]
#
If [ IsEmpty ( global::g_search) ]
Show All Records
Else
Perform Quick Find [ global::g_search ]
If [ Get ( LastError ) = 401 ]
Perform Find [ Restore ]
End If
End If
#
Sort Records [ Restore; No dialog ]
Go to Record/Request/Page [ First ]
Go to Field [ global::g_search ]
The Perform Find step, with two Omit Records actions, was the confusing part:
The above script is part of a routine to pop up a window of staff people, select a person, and then use that person’s ID to fill in some other field. The script is triggered by an OnObjectModify script trigger in a global field, g_search. As you type, FileMaker filters the list of staff people using the Quick Find feature. The problem is, errors with Quick Find in scripts don’t work exactly the way I would expect.
When manually performing a search, using either Find mode or the Quick Find toolbar field, when there are no matching records FileMaker will alert you with a message stating “No records match this find criteria” (which is error code 401). If you get this message in Find mode, you have the opportunity to modify your search or cancel it completely and return to Browse mode; using the Quick Find field, you just get the error message. Either way (unless you modify your search and are then successful), you are left with your original found set.
With scripted searches, that’s not necessarily true. With the Perform Find step, if no records are found you’ll get the error message, but then you will end up with a found count of 0 (unless additional scripting modifies that). Usually, I’ll use the Set Error Capture [On] step to surpress FileMaker’s standard dialog and provide my own custom message. In most of my solution, users expect they will end up with no records found when they search for something that doesn’t exist.
But the Quick Find step works differently. Just like manually using the Quick Find field, no matching records leaves you with the original found set. Without Set Error Capture [On], you get the “No records match this find criteria.” Since this script is running each and every time you edit the g_search field, I didn’t want the user to see a multitude of error dialogs; I just wanted the found set to become empty.
What was worse, though, was that when I included the Set Error Capture [On] step, it ended up showing seemingly inaccurate results. The error message was suppressed, but, unlike with the Perform Find step, you would still have a found set. You might type boyyyyyyyy in the g_search field, and you would still see staff member Lani Boyd, the result of the last successful Quick Find.
So my script tests if Get ( LastError ) is 401, and if so omits all records. Now, a simple way to omit all records is:
If [ Get ( LastError ) = 401 ]
Show All Records
Show Omitted
End If
But that causes all the records to be loaded first before being hidden. What I really want is a simple Omit All Records script step. Since that step does not exist, I use the Perform Find step in question to omit any record where the staff id is either empty or has a value; by logical necessity, that would be all records.
Now, as you type boy the records are filtered to Lani Boyd, but once you type boyy, no staff people appear.
| Download Sample File |
