HotDocs Author WorkflowCreate a template Add placeholders Group variables in dialogs Upload a template Create a script

Local Variables Overview

A local variable is a component you create and use only within a computation or dialog script to represent an unknown value pertinent only within that script. Using a local variable instead of a regular variable in these situations makes your complex HotDocs scripts more maintainable and easy to read, because a local variable does not show up in component lists and therefore requires no extra explanation of its use for whoever maintains your templates in the future.

Expressions cannot have local variables.

In Computation and Dialog Scripts

When writing more complex computation scripts, you may need to create a temporary or special-purpose variable that is only used or needed in a particular computation or dialog script. Such a temporary variable creates a maintenance burden since it always shows up in component lists and can require extra explanation for whoever maintains your templates in the future. To make your HotDocs scripting more maintainable, and easier to read, use local variables in these situations.

A local variable is somewhat similar to a regular variable, but instead of being usable anywhere in your template, it is only defined in the "local" context of a specific computation or dialog script. Local variables are useful in scripting situations where you would otherwise resort to defining a regular HotDocs variable just to keep track of temporary information that is not meaningful anywhere else but in this one script.

As an example, suppose you're writing a computation to remove spaces that may have been entered as part of an account number. You could do this using a WHILE instruction (link) to loop through each character of the account number, removing spaces as you find them. In this example, the local variable is Index:

SET Index TO 1

WHILE Index <= LENGTH( Account Number )

IF MID( Account Number, Index, 1 ) = " "

SET Account Number TO FIRST( Account Number, Index -1 )

+ LAST( Account Number, LENGTH( Account Number) - Index)

ELSE

INCREMENT Index

END IF

END WHILE

Notice how this script relies heavily on the “Index” Number variable. It keeps track of our position as we look through each character in the account number. This is a good example of a variable that should be defined “locally” instead of being defined in the Component Studio (as you would have done in earlier versions of HotDocs). As a local variable, Index is meaningful (and has an answer) only in the context of this script. You can create a local variable called “Index” in another computation as well, but the two would be isolated: setting one computation’s local Index to a certain value would have no effect on the other computation’s local Index. In fact, local variables do not store their answers in the answer file like regular HotDocs variables. These answers are stored in a special temporary location and are discarded as soon as the computation or script finishes running.

This table summarizes the differences between traditional HotDocs variables and local variables:

  Regular Variables Local Variables
Defined in Component Studio The Script tab of a Computation Editor or Dialog Editor
Usability / Scope Anywhere: in the template itself, in any script, or in other variables’ prompts or resources Only in the script where it is defined
Naming rules Name must be unique across all the components in the component file Name must only be unique within the script where it’s defined
Available types Text, Number, Date, True/False, Single Select, Multi Select, Table Text, Number, Date, True/False
Shows up in general component lists? Yes No
Can be asked on a dialog? Yes No
Can be saved in an answer file? Yes No
Initial or default value UNANSWERED UNANSWERED

You can use regular HotDocs variables (perhaps with “Ask automatically”, “Warn when unanswered” and “Save in answer file” all turned off) in every instance where you could use a local variable. However, there are advantages to using local variables when possible, and these advantages become more significant as your template automation projects grow larger and more complex:

  • Large or complex component files are easier to maintain when component lists are not cluttered with temporary variables.
  • Naming local variables is easier, and scripts using local variables can be easier to read, because the name only has to make sense in the context of the script where it’s defined and not in a global component list. In the above example, it is realistic to call the local variable “Index” instead of needing to call it “Account Number Index Temp,” for example.
  • Reusing components by copying them from one component file to another becomes less complicated because such copy operations no longer need to bring along additional temporary variables.