FileMaker’s native functionality for saving finds is great for drilling down to frequently needed found sets without requiring users to do all of the work manually each time they want to see a subset of records. This is a great feature for users but the dialogue to edit finds lacks some affordances that would make it easier to adopt. And sometimes the requirements has no status bar, and the access to Open Edit Saved Finds is removed. What if users wanted to share their saved finds?
This is what I came up with to save, store and share finds—allowing users to build their own reports, while also helping me learn more about FileMaker…
Anatomy of a find request
The things we need to reproduce a find are straightforward. The contents of the fields on the layout and their TOs or table occurrences, the number of requests along with what type of request each is (Include or Omit), the layout name, the type of find it is and which kind (Perform, Constrain, Extend).
Caching finds
The OnModeExit script trigger on the layout is used for it being a pre-event firing trigger, allowing us to see the criteria before the find occurs. We didn’t want this process running the whole time, so we have the user initiate when they want to start storing finds by checking a global variable before caching.
Fields: Since we won’t know which fields are going to be populated we make use of design functions to determine what fields are on the layout. When then process the list to determine if we even want the field before evaluating it (I was omitting global fields) and what value it had if any.
Find type and requests: Here we can capture the count of requests and their omit state. Since we are supplying the UI for find mode we can also know what find is being used from the parameters passed in.
Temp storage: Now we have all our pieces we need to organize it, so we can properly display the find to the user for review. This was built before we had JSON functions in FileMaker, so I used XML organize the find for retrieval later by storing it in a global variable.
Reviewing and saving criteria
Once we have finds to display I realized that the field names in the table sometimes (frequently) didn’t match up to the label on the layout which was going to be a hurdle. That is until I was pointed at the possibility to store it in the table as well but in the comment of the field. Here I again used XML in case we had some valid comments for the field to store the user friendly name which can be accessed with another design function.
With that, we could display something that was easier for the client to interact with. By allowing the navigation of cached criteria in a well-known record like way combined with familiar icons to save or dump them as they needed. Which then shows up in their list of reports for use later.
Sharing
A simple flag field in the stored criteria record determines if the record is visible for another user when they browse shared reports, which we display in a virtual list for portability.
A typical approach to reporting is to script most of the criteria with some options available via parameters. Since their reporting requirements were so detailed and changed often, we saved substantial amounts of time by letting the users build the criteria as a part of their normal workflow process.