FileMaker Indirection (and how to find those instances)

The latest version of FMPerception (16.1.1) includes a new report: Indirection Sources for FileMaker. What is FileMaker indirection, you ask? Let me illustrate with an example.

I’m standing, somewhere near a corner, at the Welcome reception for DevCon 2018, with some beverage in my hand. Someone comes up and talks to me and asks who the FileMaker community Award winner was last year. I say “Josh”. “Who?” they ask. “Josh,” I say. “Which Josh?” I point to the middle of the room. “That one.” “There’s lots of them,” she says. Finally, in desperation to go back to my silent-corner standing, I walk to the middle of the room and drag the correct Josh over to where the woman awaits. “This Josh” I say.

That, friends, is Indirection.

Indirection, in software development, is tightly defined as referencing something by name rather than the value itself. In FileMaker, we often use indirection. We reference the name of something rather than the thing itself. It sounds like a big no-no, but that’s far from the truth. Indirection is useful and valid, but it does require some “knowing what I’m getting into” thought. You have to be aware of its use in your custom app.

FileMaker Indirection, Described

Let’s dive into FileMaker indirection a bit more by using the story above and two script steps.
In my story above, I first used the person’s name to whom I was referring. I said the word “Josh”. I could have even spelled it for her: “J-O-S-H”. In FileMaker, we can use the script step Set Field By Name [] and literally type in the field name: Set Field By Name [“Students::FirstName”]. Both of these are indirection because they refer to the name of the object (person or field).

When I went over and brought the actual award winner person to the woman, I directly pointed to the person. In FileMaker, we can also use the script step Set Field[]. If I use Set Field[Students::FirstName] I am directly pointing to that field (FileMaker is actually using the internal, unchanging ID of the field ). I’ve removed the indirection by specifically pointing to the object (person or field). My act of physically pointing to the person works even if, while walking across the room, Josh decides to change his name to George.

Examples of FileMaker Indirection

As we said before, FileMaker indirection is fine. Indirection allows us to be clever in our coding (see the links below for ideas). However, it will cause problems when a field name or layout name or table occurrence name is changed by a developer other than the original one (or by the original developer who forgot they used indirection in a script step).

Other Thoughts on FileMaker Indirection

There have been many discussions about indirection in the past:

DBServices wrote a few posts on indirection, examining what it is and how to code around it.
Wim Decorte at Soliant Consulting has talked about it in reference to ExecuteSQL (a common indirection source)
Mike Mitchell spoke of indirection at FileMaker DevCon 2017. Read his notes and watch the video.
And we have discussed it in terms of the function GetFieldName().

Each one of these also give some good ideas on how to use indirection effectively. But keep on reading here.

Find Your Uses of FileMaker Indirection

So FileMaker indirection is a thing, and a thing we therefore should consider. And with FMPerception 16.1.1, we can examine all of our uses of indirection in a new report which points out all the script steps, functions, and field calculations in which we used something that could cause indirection.

A list of FileMaker Indirection functions, script steps, and field calculations

In FMPerception, we define FileMaker indirection a bit more loosely. FMPerception includes here any function or script step that explicitly uses a string as a parameter to reference a FileMaker Pro object. GetField() allows a string: GetField (“FirstName”) will get the value in a field of the current table called “FirstName”. But when the field’s name is changed to “First_Name”, this function breaks.

FMPerception also includes functions or script steps that are signposts for possible indirection issues. One common function: Get ( LayoutName ) is used many times in navigation and logic. Something like:

 If [ Get ( LayoutName ) = “Students”]
 //Do some code here
 End If

Get ( LayoutName ) is not indirection exactly, but it often is used as shown above, where the logic checks this function against a string. This logic could break if the layout named “Students” is changed to “Students_Detail”,

FMPerception counts the number of times a particular function or script step is used and lists all the places you used the the functions listed: in a script step, a field definition, conditional formatting logic, hide-field logic, custom menus . . . anywhere we use a calculation window. The report also includes script steps that include indirection such as Set Field By Name[]. Both the count and each instance of a function gives you plenty of information for your consideration.

How this is Helpful

I took a system upon which I’m currently working, created an XML DDR, and opened the DDR up in FMPerception so that I could examine my file as it is mid-development. As I examined the Indirection Sources report, I stopped and considered three things.

First, I got to consider how each function or script step is used and where it is used. I can see in my 20 uses of ExecuteSQL that sometimes I hard-code the field name, and sometimes I use a proper custom function to reference the field. I should really go and fix those hard-coded statements.

A list of the 20 instances of ExecuteSQL

I’m using ExecuteSQL () 20 times in my custom app.

Second, I can consider the sheer number of indirection uses for a decision on how much to change schema names. If I’m using Get ( LayoutName ) = “Students” 100 times, I probably do not want to change the name of the layout referenced here. If I do want to remove this indirection source, I can use methods described in the links above. This consideration may be useful in determining how much work it will be to maintain and add to a newly-acquired system.

Third, the report made me consider indirection as I continued to develop. Every time I used ExecuteSQL () I made sure to use custom functions to get the reference of each field and table in the statement.

FMPerception provides another clear view into your custom app through the Indirection Sources report. It will be useful for many developers who are taking over a system and for monthly maintenance. We think it will be a valuable tool for anyone looking to tighten up their system and make it better. If you’ve not yet tried it out, head over to the FMPerception page to read more about it and give it a try.

Trackbacks/Pingbacks

FileMaker 19 Execute FileMaker Data API Script Step - Geist Interactive - […] This is whole query, including the “layouts” key is a source of indirection. Use FMPerception to highlight all the…
FMPerception 19: Ready for Claris FileMaker 19 - Geist Interactive - […] FMPerception includes Execute FileMaker Data API and Perform JavaScript in Web Viewer as indirection sources. As you go about…