Overview
ScriptClasses allow you to create a repository of class libraries, methods, and functions that you can use across the application. You can call them from tasks, other classes, and the display's code behind functionality.
Configuring ScriptClasses
To create and configure a new ScriptClass follow the steps below:
Access Scripts → Classes
Click on the plus icon.
Input a class name and description, select the desired language and choose the domain of the class.
Choose to either create a new code or import one from an existing library.
Choose the content type for the class.
Click Ok.
Now, you can double-click the newly created row to access the Code Editor, where you can insert the code for the ScriptClass.
To edit a property of an existing object, click the desired property to select it and click it again after a second to edit it. See a list of available properties in the next section.
The image below illustrates the process described above.
Built-in ScriptClasses
All solutions include the following built-in ScriptClasses:
- ServerMain: The methods library available for all server tasks.
- ClientMain: The methods library available for all clients.
ScriptClasses Configuration Tables
The following is a table describing each available property field for ScriptClasses:
Property | Description |
Name | The name of the class. |
Code | Specifies the language used for the code of this Class. By default, this is the language you selected when you created the solution. |
Domain | The location where the class executes, there are two options:
|
ClassContent | The type of the content in the class (Methods or Namespace) |
Edit Security | The security to enable who can edit the tasks. |
Build Order | The order to build the classes. |
Build Status | The Status of the class code from the continuous compiling process.
|
Build Errors | Displays any errors encountered during the last build. |
Description | The description of this class. |
Circular References
A circular reference occurs when two classes mutually depend on each other. For example:
- Class A has methods or attributes that reference Class B.
- Class B, in turn, has methods or attributes that reference Class A.
This structure creates a “circularity” between the classes, leading to compilation failures and complicating code maintenance.
How Compilation Caching Works with Circular References:
When Saving a Class Individually: When a class (e.g., Class A) is saved, the system caches the last successfully compiled version. Therefore, if Class B references Class A, and Class A is then altered in a way that causes a compilation error, this error may not immediately appear in Class B because the cache retains the last valid version.
During a Complete Solution Build: During a full build, the cache is cleared, and all classes are recompiled from scratch. In this process:
- If there are circular references and one of the classes contains a compilation error, none of the classes will compile successfully. To resolve this, one of the circular references should be temporarily removed (commented out or deleted), allowing the successful compilation of one of the classes by saving. Then, the removed reference can be reinserted in the other class, now correctly compiled.
We emphasize that using circular references is not a recommended practice. This kind of mutual dependency compromises code stability and maintainability, complicates debugging, and leads to complete build failures.
Recommendations:
- Guide users to avoid circular references between classes whenever possible, as this will simplify compilation and maintenance.
- Include an explanatory note that, while the system does not block the creation of circular references, this practice is not recommended, as it often leads to compilation difficulties and stability issues.
In this section: