#Filemaker baseelements sftp example code

This function actually takes a direct reference to the field and translates it into a name. The magic is being done by the function GetFieldName (). Also now field CONTACT::firstName is considered as referenced by this script in DDRs. In this case, if I change the field name to first_Name, that script will still work. So we should try to avoid hardcoding the following in our solutions:įollowing this guideline, for our example we want to get rid of the hardcoded TO names and field names and instead, dynamically grab the field's name. With that being said, how do we write robust indirection? Robust indirection will try to dynamically grab an object name and use it in your solution. So if you use analysis tools like BaseElements to check where field CONTACT::firstName is referenced, that script will not be included. The second issue is that indirection is not considered as a reference in DDRs. In our example, if I rename the field 'firstName' to 'first_Name', it will break my script because there are no fields named 'firstName' anymore. It looks normal at first glance but there are actually two issues with this approach and with many other uses of indirection: The first issue is that if not treated carefully, renaming objects may break indirection.

#Filemaker baseelements sftp example code

For example, I can use a few lines of code to tell a script to do something if the user is in field 'CONTACT::firstName'.

Indirection in FileMaker refers to the ability to reference an object (table, layout, value list, field, script) by its name, instead of its internal id. What is indirection (and what could go wrong with it)?