This article from InSource shows the different options available of where to declare variables for Application Server Scripts, and discusses some of the reasons to choose one option over the other.
- Author: Dillon Perera
- Published: 12/26/2016
- Applies to: Wonderware Application Server 3.0 and higher
Wonderware Application Server's scripting environment allows multiple places to declare variables. When deciding which option to use you must first decide what the variable will be used for, and who will need access to its value.
Option 1: Declaring the variable inline using the DIM statement
Using this method allows programmers to build variables as needed. Variables created this way will are created at runtime when the script executes, and are destroyed when the script finishes execution. These variables are only available to the script who created them, and cannot be accessed by other objects, or through ObjectViewer.
Option 2: Using the Declarations section
Using this area of the script editor creates your variables similar to a DIM statement, but these variables are not destroyed when the script finishes execution. Instead these variables persist and are reused for each run of the script. Because of the variables are not destroyed the programmer is able to continue to access values after execution, for example if trying to implement a counter. This can also be a problem for users who are unaware of this persistance, as it will mean that on the next execution of the script the variables will not be reset to default values (0, blank string, etc..). Variables created in the Declarations section are still only available to the script in which they are created.
Option 3: Creating the attribute in the Field Attributes, UDA, or Attributes tab
Creating an attribute in the object allows the variable to act similar to a variable created in the Declarations section, in that the value is not reset on each run, but also allows the value to be accessed from other objects or from ObjectViewer.
When deciding which method to use, consideration should be given to how often the script will run, and who should have access to the variable's contents.
How Often will the Script Run?
This question is important because the creation and destruction of variables does involve a small amount of overhead. For scripts that will run frequently, using Option 2 or 3 may be more efficient as the system will only have to create the variable once. For scripts which run infrequently, Option 1 would be more efficient because the variable will be created, and then destroyed upon completion, freeing up system resources to be used by other tasks.
Who should have access to the variable's content?
This question is important to ensure that only those required have access to your data. For example, if using an attribute created via Option 3, a user could accidentally change the value of your attribute through ObjectViewer, causing your script to behave unpredictably. When developing your scripts, variables should be created to limit access to their values as much as possible as a best practice.