Welcome to the Cyara Knowledge Center

User Defined Variables

As well as system variables, which are pre-set, variables can be assigned by script commands which return variables, and by the Let command which allows you to create variables at any time. All variables have global scope (are available to the entire script once created).

The Let command is used to assign a value to a variable like so :

The first time a variable is assigned a value, that variable is created. Subsequently, it's value is modified.

Variables can then be passed into other functions as one of the parameters. For example, assuming the above Let command has taken place, the following command will display a message box containing the words 'Freddy Mercury' :

If Name did not exist as a variable, the message box would simply display the word 'Name'.

Commands always check to see if a parameter passed to it is a variable. If a variable with that name exists, the value assigned to that variable is used, otherwise just that literal value is used.

All commands which accept a value can also accept a variable in place of that value.

For example, the following command would send the text 'Freddy Mercury' to the current window :

In some cases a variable must be embedded within a string. This can be achieved using the % operator. In the following example a message is displayed saying 'Hello Freddy Mercury' :

The system variable CRLF can be used to force a new line in a message box. Therefore, a list can be built up like so :

It is possible to ask the user for a value, using the Input box :

Input>path,Please enter directory to create : 

This would prompt the user to enter a directory name to create, which would then be assigned to the variable path. We could then use it in the CreateDir command as follows :

The If command can be used to check the value of a variable :

Arrays

Arrays are essentially ordinary variables with a numeric suffix. The suffix format can take any format you prefer, although built in functions which return arrays use _n where n is the numeric identifier.

Array examples:

ArrayDim>Names,3 
Let>Names_1=Fred 
Let>Names_2=Sally		  
Let>Names_3=Geoff
 
Let>k=2 
Message>Names_%k% 
Let>Names_%k%=Louise 
		  

Arrays created by MacroScript functions are displayed in the debugger watch list as <array> and can be expanded by double clicking to reveal the array contents. This avoids the watch list being cluttered up with all array elements and can speed up debugging scripts with large arrays. To get the same behaviour for user defined arrays use the ArrayDim command to create an empty array.

Using VBScript Arrays:

Use the VBEval command to get the value of a VBScript array variable into a MacroScript variable:

Scope

By default variable scope is global. That is, any variable created in your script will be available anywhere else in your script, including in any subroutines. Any variables created within a subroutine will remain available to the rest of the script.

A word or two should be said about other scripts called or included by your script. The Macro command executes another macro. That macro is kept separate from the calling macro. In this instance variables are not shared, so scope could be said to be local. Using the Macro command is like calling a separate process via the command line. Variables can be passed into the called macro via command line parameters, but script variables within the code are not shared. In contrast the Include statement, rather than "call" the included macro file, literally includes the code from that file within the main script. Include is rather like copying and pasting the code from the Include file into the main script file at run time. Therefore in this instance variables are shared as the Included script becomes part of the main script.

Local Scope

It is possible to force new variables to have only local scope by setting LOCALVARS to 1. After setting LOCALVARS to 1 any variable creations or assignations will have local scope. I.e. if LOCALVARS is 1 and a new variable is created within a subroutine that variable will only have scope within that subroutine. It will no longer be available to the rest of the script once that subroutine has terminated.

With local scope enabled subroutines can still see any "global" variables. I.e. variables created in the main script or parent subroutine will be available to the subroutine. But attempting to modify an existing variable while LOCALVARS=1 will create a local version of that variable if it doesn't already exist locally. In other words all variable assignations or creations will have local scope.

Therefore if LOCALVARS has been set to 1 and you need to modify a lower level variable you will need to set LOCALVARS to 0 first.

Note that variable look-ups are recursive down through the variable table hierarchy so when retrieving values a match will occur against a parent level variable first. In other words variable look-ups "drill down" through the variable table hierarchy until a match is found. E.g. if we are at level 2 and there is a variable in the root table (level 0) and another with the same name at the parent level 1, then the value of the parent subroutine's variable will be returned (level 1). If you want to override this behaviour to specifically force only level 0 look up, set LOCALVARS to 2.

Example:

Explicit Variable Resolution - VAREXPLICIT

You can tell the script only to resolve variables that are contained within % symbols and to leave anything else as literals by setting the VAREXPLICIT variable to 1:

The default is 0 and will cause default behaviour as described above - i.e. the script will look at any parameter to see if it is a variable. If a variable with that name exists, the value assigned to that variable is used, otherwise just that literal value is used. Setting VAREXPLICIT to 1 stops this behaviour and tells only to resolve a variable if it is contained within % symbols. E.g.

In this case the first Send> command will send the literal 'Name' and the second would send the value 'Fred'. In the following example, which is the default behaviour, both Send> commands would send the value 'Fred':

Ignoring Spaces - IGNORESPACES

By default, spaces are seen as regular characters and are included in variable assignments. E.g. The following line..

.. would create a variable called "a " with the value " 5".

Normally, therefore, you should use:

But experienced programmers are used to the language ignoring spaces. This can be achieved by setting IGNORESPACES to 1:

This would set variable "a" to the value 5.

If spaces are ignored then strings that need preceding spaces will need to be delimited. To do this use {"string"}

Ignoring Spaces - IGNORESPACES Example

System Variables

Environment Specific Values

• OS_Ver - Operating System
• WIN_DIR - Windows Directory Path
• SYS_DIR - Windows System Directory Path
• SYS_NATIVE - Native System Directory Path Bypassing 64 Bit Redirection
• TEMP_DIR - Windows Temp Directory Path
• DESKTOP_DIR - User's Desktop Path
• USERDOCUMENTS_DIR - User's Documents Path
• PROGRAM_FILES - Program Files Folder (Will be x86 folder if running on x64)
• PROGRAM_FILES_NATIVE - Native Program Files Folder (e.g. "Program Files" not (x86) on x64)
• OS_PLATFORM - Operating System Platform - i.e. WIN32 or WIN64
• USER_NAME - Current Username
• COMPUTER_NAME - Computer Name

Runtime Variables

• CWD - Current Directory
• _Line_NUM - Stores the current line number being executed

Useful Printable and Non-Printable Characters

• CR - Carriage Return
• LF - Line Feed
• CLRF - Carriage Return, Line Feed Combination (to force a new line)
• TAB - Tab Character
• SPACE - Space Character
• COMMA - Comma Character
• NULLCHAR - Null Character - Chr(0)
• DECIMAL_SEPARATOR - Sets/retrieves the character used as the decimal separator in floating point/currency numbers. Default is "."
• THOUSAND_SEPARATOR - Sets/retrieves the character used as the thousand separator in numbers. Default is ","