What is Indirection?

Indirection in FileMaker refers to the ability to reference an object by it's name, rather than by it's internal id. For example, when you setup a perform script step, and choose a script to perform, FileMaker stores the id of that script you're performing and saves that. That way, you can alter the name, or move the script within your file, and it will always still work. The same applies to fields used in calculations, FileMaker breaks the calculation into it's various parts and keeps all of the field, table, and custom function id's so that you can also rename those without breaking your calculation.

Indirection is when you are not referring to an object directly, you're instead referring to it by it's name. For example you setup a GoToLayout script step that chooses the layout by a calculated name. If your calculation for the name is fixed, but you change the actual layout's name, it will no longer be found and your script step will error.

There are more and more ways in FileMaker these days to use indirection to refer to an object in FileMaker. For example we now have these functions :

GetField ( "fieldname" )
Evaluate ( "myCustomFunction ( tablename::fieldname ) " )

that can refer to fields from a calculation. Also there are things like :

ValueListItems ( Get ( FileName ) ; "ValueListName")

As well as that it's possible to refer to layouts by number and also by calculated name. But these don't have to be simple calculations like the above. They could also be

GetField ( othertable::field )
Evaluate ( $$VariableName )
ValueListItems ( "otherfile" ; $VariableName )

in these cases the actual name to look for is coming from a dynamic location. In short there is nothing that BaseElements could do to work out what that variable is actually referring to at "run-time" when it's in the users hands. There may be cases where it's simple and in theory BE should be able to work it out. But there will be cases where it's impossible to tell, like if the layout name comes from a field that has user entry allowed. BE has no way of knowing what the user will type.

In short it's now possible in FileMaker to refer to objects using this indirection which could mean they show in BE as being unreferenced - if they are also used somewhere else.

Is this a limitation of BaseElements?

No, it's a limitation of any analysis tool whether it uses the DDR for it's data or not. It's a limitation we've now got because of the additional options we've got to use indirection to refer to objects in FileMaker.

I think the indirection options are worth the extra hassle we've added - they give us a lot more options and flexibility for our design choices. For example, you could have one GoToLayout script step in your entire file that goes to every layout it needs via a calculation.

How will I know if my solution is using Indirection?

As of version 1.3.0, BaseElements added a feature to find any examples of where you're using Indirection and alter the way it reports Unreferenced items. This means you can be alerted in advance if an item is Unreferenced, but possibly being referred to elsewhere.

BaseElements uses a simple checkbox to show if an object or item is completely Unreferenced. In version 1.3.0 and later, it also keeps track of whether or not objects are possibly being referred to via Indirection. There are four things that could be referred to Indirectly :

• Custom Functions
• Fields and Table Occurrences
• Layouts
• Value Lists

Custom Functions are found using Evaluate type functions. Fields and TOs are found via Evaluate, GetField and also Field Attribute functions. Layouts can be found via some of the Layout attribute Get functions, and GoToLayout or GTRR script steps. And Value Lists are found via ValueListItem functions.

How does BaseElements report Indirection?

If an item is Unreferenced, but your file is using Indirection for that item, it will change the look of the checkbox from a check, to a dash. You can still search for these items, as the actual value of the field is still a 1, but there is a calculated image field over the top of the checkbox that shows the dash.

Also the text colour of the totals on the DDR and File layouts has changed. It will change the Unreferenced green count to orange where the item could be referenced using Indirection.

So you can still see, total and search for unreferenced items, but you're now alerted if you should take greater care when deleting these items.

Is there anything else I can do about this?

There is also a function in BaseElements to not count an object as Unreferenced if it uses a specific naming convention. This is the [ ] that are around non deletable accounts or privilege sets. You can name any objects like scripts or other objects with the same conventions and they will not be reported as Unreferenced.

There is also an upcoming item on the todo list to set your own naming conventions for objects that are not Unreferenced. So for example you setup some conditions that say if the layout name ends in "DND", or if it has a "*" in the name, or it's surrounded by [] then it isn't unreferenced, and it won't appear in the totals, or have it's checkbox set.

If you'd like to see BaseElements do something specific, let us know via the comments and we'll do our best to include it.

Are there any other limitations?

First be aware of the limitations in the DDR output. There are 2 significant limitations that you should be aware of. We consider these bugs in the current (11v2) version of the DDR output, and have submitted them to FMI as such.

• The DDR doesn't output any information about layout parts. And this includes fields used as sub-summary break fields. This won't catch many people as a field used just for this purpose would also need to be in a sort button or script and BaseElements will reference it there.

• The DDR doesn't include elements used in a calculated XML or XSLT import. This is when doing a script step or button that does an XML import and you choose the "calculation" option from the radio buttons, and use fields in your calculation. There is an easy work around for this that you set your calculation to a variable, then use the variable in the import dialog instead. This is picked up as a warning on the warnings tab.

Second be aware that there are still yet more ways that you can reference items that BaseElements can't catch. Things such as external methods of accessing the database like web publishing or ODBC. And finally that BaseElements can only work with the files you have selected for use in the DDR. Any other files that reference the current one will not be included.