Perform Extended Find

Chances are there’s some more official Filemakery term for this, but I’ve spent too little time with other developers to learn all the words.  Except robust.  God knows, you have to know the term robust if you’re going to be a developer.

I mentioned on Wednesday that I use global fields to allow users to search records.  If you have your users searching via the data fields, you’ve got several problems.  First, if their first search yields no results, then the search won’t automatically work the next time because there are no records present.  Second, if your user starts in browse mode or accidentally finds herself in browse mode, she could accidentally alter existing data while trying to enter search criteria.

So I have two search mechanisms I use.  First:

It’s a fuzzy clip, but I think you can make out the search bar.  This is a trigger (on enter) field that quickly grabs the temp global value and searches likely fields like name, city or school.

But say the user needs to find all the male students at a certain school in third grade.  They click on the magnifying glass to go to the Extended Search layout:

 

Still a little blurry, but I’d rather spend the time explaining than resolving the problem.  Each field on this layout is a global temporary field:  temp1g, temp2g, temp3g etc.    There are no triggers on these fields, so the user can enter as many criteria as they want — and leave blank as many as they want.

For controlled values, use the same drop downs you did on the data fields.  Only do this if you know the user won’t need to enter a range.  In my example above, the user is not able to search for grades 1-4.  The drop down limits him to a single grade.

This is most likely to be an issue with dates.  You’ll probably never use a drop-down calendar in an extended search, because users usually need to enter date ranges.  Unless you train them, they won’t intuitively know to use an elipsis for a range, so I always include a little explanation:  

Once the user is satisfied, they hit the “Go” button.  Or “Search” or “Done.”   Just FYI, the word “Robust” doesn’t actually work here, but no worries — you’ll have lots of opportunities to use it.

The resulting script should set variables for each field.  If the field is empty, no worries; it just goes on to the next field.  Then Find Mode, go to a data layout, set the fields and search.  Here’s one of my scripts:

Pretty, right?

In answer to the questions I’m pretending you asked:

Why did I Enter Find Mode before going to the layout?  Because, ugh:   On Layout Enter triggered scripts can really mess with the script you’re running.

Too often, an Enter List View script Shows All (I don’t like), or searches and only shows Active records.  In a search, you may need to see a specific found set, or in a Loop you’ll need to go back to the record you started on.  they can Show All when you really needed your found set to stay the same.

Also, if you go into a complex layout for a find, your user may get to wait while records sort and calc and summary fields do their business all over your search before they even go into find mode.

Go into find mode first and skip that trip.  Your user will never even see the change in context.

Why did I go to the detailed Form View instead of the List view where we ultimately end up?  Because all of the things are in the detailed view.  This allows us to build a list of records using criteria that didn’t fit in the list view.  The user can still click on the individual records to see all the details.

______

You’ve just enabled your user to create quick, customized reports — now she’s back in list view, so she can just click the print icon and print only the records she selected.