Reserved symbologies

  • ~ Tilde is the reserved character to indicate the private nature of an element such as ~privateLetVariable or ~PrivateCustomFunction, $~privateScriptVariable or $$~PRIVATE.GLOBAL.VARIABLE.
  • ! Exclamation mark is a reserved symbol to indicate the non-relevance of something within code. Just as in many languages where it is used to negate or present the opposite of an operator (such as != meaning 'not equals' within PHP where <> or ≠ is not equals within FileMaker) it is most often used with variable declaration which uses the Evaluate() function.

Reserved variable names

  • $$ERROR or $error is a reserved variable for the storage of an error result. The most common is FileMaker's own Get ( LastError ). This variable will almost always be a numerical value in order to follow the conventions outline by FileMaker's own error handling. It is, however, not limited to FileMaker's Get ( LastError ). When augmented by a complimentary variable such as $errorType, the contents of $error may not contain a FileMaker specific error code.
  • $$TEMP or $temp is a reserved name for a temporary global variable. This variable is NEVER used to store persistent data across multiple scripts and it can be assumed that it can be overwritten at any time.
  • $~this is a reserved prefix for internal use within custom functions. In order to avoid overwriting any script variables you should prefix variable declarations with this value. For example $~thisCounter would be used as a recursive counter within a Custom Function. To further prevent any name collision, using the name of the function itself is preferred. Such as $~thisLeftCharsCounter where the $~this is the prefix, LeftChars is the name of the Custom Function and Counter is the descriptor.
  • (deprecated) $checkScriptName is a reserved variable for Script parameter custom functions

Reserved custom function names

Reserved custom function prefixes

  • # (hash or pound) is reserved for Name/Value pair functions (primarily for script parameters)
  • Triggers is the prefix for the class of custom functions which deal with script triggers.
  • Error is the prefix used for the Error handling section.
  • No labels

8 Comments

  1. Anonymous

    Like the ides but how about other reserved words for the temp storage given that there already is a clipboard on each platform. SCRATCH, TEMPSTORE?

    1. I'm totally flexible on suggestions here. I can go with whatever makes sense to most people. The objective with the CLIPBOARD element is to address the fact that most of the time, we all end up adding some type of global UTILITY field to tables. Let's just pick and name and use it. (smile)

  2. Anonymous

    UUID would no longer be on the reserved list considering its new name and reserved namespace with Filemaker 12.

    Russell Barlow

    1. Thanks Russell. Got that one fixed per the new UniqueID custom function suggestion.

  3. What's the definition of a private global variable?

    I think a clear example of where a private variable should be used is in the Triggers* custom functions, since the variable is only meant to be accessed by the custom function.

    How about a global variable that is only meant to be accessed by a script? As an example, I use a script that saves the active tabs for all layouts in a global variable, which it also uses to get the active tabs from when restoring. Like the Triggers* custom functions, I think this qualifies as a private global variable.

    Now, to take it a step further, what if a script and a field access the variable? There is an example of this here: http://fmforums.com/forum/files/file/28-view-selected-child/. Now, it seems like I've gotten into a grey area. I think this should NOT be a private variable (no ~ prefix), but I'd like to know how others define 'private', in this context.

    1. From the other uses of the 'Private Variable' in the standards, private = calculation level variable.  Which is not available outside of the calculation...and can't be referenced.

      It is also is used to avoid possible conflicts between variables used in Custom Functions with those already existing or being used in a solution.

      I'll have to think on this more, because the 'private' scope of the ~ gets lost when you throw a $ or $$ in front of it.

      1. Due to the scope of variables in FileMaker, they can't be made "private" in the sense understood by developers working with object-oriented languages where the variable would simply be inaccessible. The tilde prefix may have the effect of avoiding possible variable name conflicts between variables used by custom functions and other variables in a solution, but I think this is only a bonus in case I mess up and forget to add suitable function-specific prefixes. Outside of calculation level variables, I think of the "~" prefix not so much as indicating "private" status, but "please don't look behind the curtain" or "don't meddle with what you don't understand; this is being handled for you." Is there a good word for that other than "private"? How about "managed"?

        I don't see any reason a script couldn't use $~managedVariables. In my own reckoning, whether or not it makes sense to use a variable marked as ~managed depends on whether you want to be comfortable with arbitrary other calculations in the solution (particularly calculations written by other developers) using or setting the variable. It's a judgement call, and I hope our conventions leave plenty of room for developers to make judgements.

        1. I like how you defined this - it helped me understand the intention of using the "~" prefix.

          I just did a little reading on private variables in other languages and it seems to me that it's definition is generally the same as it's been defined here on filemakerstandards.org. Most other languages offer some sort of internal protection to private variables, but apparently that can sometimes be bypassed if you're determined enough. So, even though FileMaker offers no protection to what we are calling private variables, the concept seems similar and I think the term "private" is a fitting one (even though I miss-understood it at first). I think it would be useful to define what we mean by private variable, though. Here's my stab at a definition:

          Arbitrary code should not access this variable directly, it belongs to a group of code which manages it's value, and provides methods for utilizing this data, when necessary.