There are four different categories of variables. When using the value of a variable, the categories are tested in sequence, so if you define a variable yourself with the same name as a system variable, it will never be seen.
Variables defined during a call retain their values for the entire call, even if the User Profile is changed by an assignment to the DIDNO system variable. Variables set in the new user profile replace those with the same name which were set in the original user profile.
As each category of variable is scanned, the longest possible variable name in the text is used. For example if you define infobox variables:
$set_var myvar1 "First Value"
$set_var myvar10 "Tenth Value"
then after this .IIF file has been selected and processed, when you write @myvar10 it will be expanded as "Tenth Value" and not as "First Value0". If, however, you defined a variable:
$set_var titlestring "My title string"
then the @titlestring would not be expanded as expected because the system variable @TITLE would be processed first (its category has precedence).
In general, we recommend never using variable names where one name is an initial substring of another. For example, if you define WORKA and WORKB, do not also define WORK as a variable. Although the system will usually sort things out (as with myvar1 and myvar10 above) this practice can make assignments in infobox logic more difficult to understand and debug.
There is one exception to the rules for expanding variable names. Variable expansions of the form @MEMOx or @BCFx (with the specific names MEMO and BCF) are processed specially, and only an exact match is expanded. Thus if you have defined MEMO3 in an FS file, but have not defined MEMO30, then writing @MEMO30 in a cover sheet template file will not cause the value of MEMO3 followed by a zero to be expanded. This feature allows you to include a large number of @MEMOx expansions in a cover sheet template file, and have them correctly expand to blank if a smaller number of $var_def MEMOx commands have been created in the FS file.
The categories of variables, and the sequence of testing them, are as follows:
1. System Variables
There are many useful System Variables, listed in Appendix D, which you can read or write. These variables are valid at one or more of three stages of a transaction:
| • | valid during a fax-on-demand request. For example @PAGES contains the number of pages so far requested, and can be used in infobox logic. |
| • | valid during an outbound fax transmission. For example @TPAGES contains the total number of pages to be sent, and can be used in a cover sheet template. |
| • | valid at all times. For example @DATE1 contains the system date. |
Check the documentation for these variables to ensure that they are valid at the time you use them.
From CopiaFacts version 7, all new system variable names will contain an underscore character (_). Avoiding the names defined in Appendix D, and any other names with an underscore, will therefore help to ensure that your own variable names do not conflict with CopiaFacts system variables. When assigning your own variable names, avoid choosing a name that starts with the same letters as another variable for the reasons described above.
Some system variables are 'smart' in that they cause an action to take place when you assign a value to them or read a value from them.
2. Variables Defined in FS Files, Infobox Files, and User Profile/Property Files
You can set variables in FS files which you generate, using the $var_def command. This technique can be used, for example, to pass MEMOx variables containing memo lines for the cover sheet.
Note that any variables which you define in infoboxes during a callback request are also written into the resulting FS file.
Most of your own variables will be defined in .IIF files using the $set_var command to assign or calculate a value, the $get_var command to set a value from a caller entry, or the $lookup_var command to get a value from a DBF database record.
The $var_def command can be used a User Profile to assign default values for IIF and FS variables, or as a convenient way to set semi-permanent global values for use in cover sheets for the application. The definition of the variable only lasts for one call.
You cannot set writeable System Variables using the $var_def command.
3. Variables Defined in the Configuration File
The $var_def command can be used in the configuration file to assign default values for IIF and FS variables, or as a convenient way to set semi-permanent global values for use in all cover sheets. You cannot set writeable System Variables using this command.
4. Environment Variables
Any environment variable may be referenced using the @ syntax. In this case the extent of the variable name is delimited by a whitespace or punctuation character, so that for example "@TEMPORARY" is not expanded from the environment variable TEMP. Pseudo-environment variables may also be set using the $environment configuration command.
If no valid variable name is found in the above categories, the @ and the variable name, delimited by white space or a punctuation character, are deleted from the text. The @ symbol is not expanded when it appears as part of a valid DBCS character in far-east versions of Windows.
Topic url: http://www.copia.com/support/refmanual/index.html?precedence_of_variable_expansi.htm