When I am working in the Bay Area, I often carpool to Beezwax’s Cupertino and Oakland offices with Vince Menanno, the creator and lead architect of InspectorPro. Over two years of commuting, I have been bugging him to add global search to InspectorPro, so FileMaker developers can search elements across the entire DDR for any solution. Vince must have gotten tired of my nagging, because at long last we can all enjoy this functionality, in InspectorPro 7.
In this post I will share three ways I use InspectorPro’s Global Search feature to search across those elements—schema, scripts, calculations, and more—in a FileMaker solution and how you can too, to save time, money, and headaches.
Use 1: Search Error Text to Find Where to Begin Debugging
How does it happen? We all know cases where users report the strangest errors. Is that error in my solution? Perhaps, being the good developers we are, we wrote error handling code we know full well will never get hit. Until it does.
“But I wrote the code that builds that JSON. It must be a valid format!”, you may argue, but nevertheless, there it is. Now we have to find where in the solution that error exists. It could have been years since we built it, or it may be someone else’s code entirely.
Unfortunately, that error dialog does little to point developers to the right place, but it does have some fairly unique strings on which we could search. If only FileMaker Pro gave us the ability to search our code…
Enter InspectorPro 7!
I won’t go into the details of generating or importing a DDR, but after you’ve done those things you’ll see the new analysis dashboard. There on the right side, halfway down, is the object of my (and soon to be your) heart’s desire: global search. Let’s search for the title of that error dialog.
Found it! It’s in the “on timer | LOgiCATOR | Perform Find” script on line 121. (The other search result, by the way, is the calculation itself that sets the variable in the aforementioned script step.)
Click the arrow or the left side of that first search result and we can see the script step in context of the whole script.
That’s great. That made it a whole lot easier to see where the error dialog shows up, but where does the “error 99” in the If() come from in the first place? It’s not in the list of standard FileMaker error codes, so it must be something the developer set.
Global search helped us find the error dialog, but now that we are there we can use the new built-in LOgiCATOR functionality to perform an advanced search. Let’s look for all steps in that script that contain the string “99”.
Bingo! Two results. The second is where we were just looking, but the first is where that $_error variable gets set, line 51.
Having saved a ton of time tracking down where to even start, we have a minute to grab another morning cup of coffee before we return to our solution, set a breakpoint, and begin debugging. ☕️
Use 2: Deprecate Old Features and Replace With Updated Functionality
Development on FileMaker solutions never ends. It is an iterative process and the best developers are always looking for ways to improve functionality, increase performance, and take advantage of new features.
Here is an example of a “master detail” layout that was developed in the days before FileMaker 17, in which built-in master-detail layouts were introduced. That albums portal (and it’s sibling, the tracks portal, on another layout) in the middle of the screen looks great and operates well.
Dropping into the relationship graph, however, we see it is what—by FileMaker 18 standards—we would consider a “hack”. Let’s rip that out and rebuild it as a true master-detail layout.
When taking on a task such as this, I like to find out exactly what I am going to have to touch. As a developer, this helps me build a checklist to go about my work, but in the pre-sales stage it may help an account manager more accurately estimate the hours to fulfill a client request.
Those two table occurrences both conveniently end in “__MASTER”, so let’s see what that search brings up.
This doesn’t seem too bad. Just sixteen results: the two TOs themselves, two relationships connected to those TOs, six layout objects, and three conditional formats.
We won’t go into actually replacing that portal here, but one thing I like to do as I work through my checklist is to mark elements with a unique tag, such as “__DEPRECATED”. Since by doing so I am not removing anything, users can keep using the old feature while I am building the new. This works especially well when developing on a live production system (though we never do that, right?).
(If this were television, here the screen would get all wavy and we would return several hours in the future.)
So building those new master-detail portals wasn’t hard, was it? And, since our users love the rebuilt feature, we can start removing the old code. After all, clean solutions, free of old, unused cruft, make for happy developers.
I recommend an iterative process, (global) searching for our “__DEPRECATED” tag, looking at the reference count, removing unreferenced elements, running another analysis, and repeating. At the end, we should see just our two TOs, with zero references in the rightmost column. Remove those, and have an afternoon tea. 🍵
Use 3: Rename Elements So Self-Documenting Code Stays Current
Despite our best efforts gathering requirements, building ERDs, and talking with clients, what we built yesterday may not reflect a changing tomorrow. Business processes and terminology continually shift, and we want our carefully chosen entity names to remain relevant.
Sometimes we have no choice but to march on, but when time and budget permit, I prefer to update my code with the new name. Yeah, we could be lazy and change it in just the UI, but I know from experience that will just lead to confusion down the road.
While FileMaker does not have a global search-and-replace facility, we can use InspectorPro for at least the first part. For purposes of demonstration, let’s go old school and change all instances of “track” to “song”. First we’ll search on “track”, which brings up thirty-one results across an assortment of FileMaker elements: tables, fields, layouts, calculations, …. (Don’t miss that Expand button to see all the Calculations.)
As with “__DEPRECATED” in our previous task, our goal here is to work our way through the list, renaming as we go. Sometimes we’ll get things for “free”, for example renaming a table occurrence automatically renames relationships connected to that table occurrence. Again, this may be an iterative process, repeatedly generating new DDRs to see what’s left.
In the end, though, a search on “track” ought to yield zero results.
The flip side, searching on “song” ought to yield the original thirty-one results.
Optionally, we can make use of another InspectorPro feature, comparison reports, to see a list of all the changes we made.
By clicking on any one of those modification records, we can see before, after, and a “diff” of that change.
With that, our three tasks are done for today. 🍻
There is no demo file for this post (though the example file I used is based on Mark Scott‘s excellent LOgiCATOR demo file). Instead, I hope you find ways to use global search in your own solutions.