Organize reusable classes for scripts.
Reference → Modules → Scripts → UI → Code Editor | Classes | Expressions | Monitor | References | Tasks
ScriptsClasses (Reference) provide a repository of reusable code libraries, methods, and functions accessible throughout your FrameworX solution. The platform automatically manages these classes as static objects with built-in exception handling.
ScriptClasses enable code reuse across:
- Script Tasks
- Display Code Behind
- Other ScriptClasses
- Expressions throughout the solution
The platform provides automatic:
- Static object instantiation
- Exception protection
- Cross-language interoperability (C#/Python/VB.NET)
Creating ScriptClasses
Access Scripts → Classes
Click the plus icon to create a new class. Three options are available:
- Class with Methods - Standard reusable code library
- Full Namespace - Advanced .NET namespace (Visual Studio-like)
- MCP Tool - AI model integration via Model Context Protocol
Configuration Properties
| Property | Description | Required |
|---|---|---|
| Name | Class identifier used in code references | Yes |
| Code | Programming language (C#, Python, VB.NET) | Yes |
| Domain | Execution location: Server (global) or Client (local) | Yes |
| ClassContent | Type: Methods or Namespace | No |
| Edit Security | Permission level required to modify | No |
| Build Order | Compilation sequence when multiple classes exist | No |
| Build Status | Green check (success) or Red X (errors) | No |
| Build Errors | Compilation error details | No |
| Description | Documentation for the class purpose | No |
Code Structure Requirements
CRITICAL: Do not include class declarations or namespace definitions in ScriptClasses
When creating a ScriptClass with Methods or MCP Tool:
- DO NOT include:
public class MyClass { } - DO NOT include:
namespace MyNamespace { } - DO NOT include:
usingstatements directly in code - DO include: Method definitions only
- DO use: Namespace Declarations button for
usingstatements
The platform automatically wraps your code in the appropriate class structure using the Name from the configuration table.
Correct ScriptClass Format
csharp
// Methods directly - NO class wrapper, NO using statements
public string ProcessData(double value)
{
return $"Processed: {value:F2}";
}
public int Calculate(int a, int b)
{
return a + b;
}Adding Namespace Declarations
To add using statements (C#) or Import statements (VB.NET):
- Open the Code Editor
- Click the Namespace Declarations button in toolbar
- Add required namespaces in the dialog
- Never put
usingstatements directly in the code
ScriptClass Types
1. Class with Methods (Standard)
Most common type for reusable code:
- Platform manages as static object
- Automatic exception handling
- No instantiation required
- Access via:
@Script.Class.ClassName.MethodName()
Example:
csharp
// In ScriptClass named "Calculations"
public double CalculateEfficiency(double actual, double target)
{
if (target == 0) return 0;
return (actual / target) * 100;
}
// Usage anywhere in solution:
// double eff = @Script.Class.Calculations.CalculateEfficiency(95, 100);2. MCP Tool
Special class type for AI integration:
- Exposes methods to external Language Models
- Requires decorator attributes
- Methods without decorators behave as regular methods
- Available in all editions including EdgeConnect
Example:
csharp
[MCPMethod(Description = "Get tank level")]
public double GetTankLevel(
[MCPParameter(Description = "Tank ID")] string tankId)
{
return @Tag[$"Tank_{tankId}_Level"];
}3. Full Namespace (Advanced)
Advanced Feature Warning: Full Namespace is for experienced developers only. Most applications should use standard Class with Methods. This option requires manual object instantiation and exception handling like Visual Studio development.
Complete .NET namespace implementation:
- Requires full namespace and class declarations
- Manual object instantiation required
- No automatic exception protection
- Full control over implementation
Example:
csharp
namespace MyCompany.Utilities
{
public class AdvancedProcessor
{
private int counter = 0;
public void Process()
{
// Implementation
}
}
}
// Usage requires instantiation:
// var processor = new MyCompany.Utilities.AdvancedProcessor();
// processor.Process();Invocation Syntax by Caller Domain
The @Script.Class.<RowName> token form is a Code-Editor preprocessor convenience. The preprocessor that expands it runs only when the calling script compiles under the Client domain. The effect on Full Namespace ScriptsClasses (ClassContent = Namespace) is the load-bearing case:
- Client-domain caller — CodeBehind, client-side ScriptsClasses, client-side expressions — can write
@Script.Class.<RowName>.<Method>(...)and the preprocessor expands it into the underlying C# call. - Server-domain caller — server-side Tasks, server-side ScriptsClasses, server-side expressions — must invoke a Namespace class through its direct C# fully-qualified name:
<Namespace>.<ClassName>.<MethodName>(...).
csharp
// Server-domain caller invoking a Full Namespace ScriptsClass
double result = MyCompany.Utilities.AdvancedProcessor.Process();The mismatch is a quiet failure mode — an @Script.Class.<Namespace-class>.<Method>() reference written inside a server-domain script does not raise a domain-mismatch warning; it produces an unresolved-identifier compile error at the call line, with no hint that the cause is the caller's domain. When the "@Script.Class.<name> does not exist" error appears against a Namespace-type class, check the caller's Domain column first.
Standard Class with Methods ScriptsClasses are unaffected by this restriction: @Script.Class.ClassName.MethodName(...) resolves from both domains because the platform pre-instantiates them under a known static path.
Built-in Classes
All solutions include:
ServerMain
Global methods library executed on server:
- Available to all server-side scripts
- Runs in TServer main thread
- Pre-instantiated by platform
- Special entry points for server initialization
ServerMain has special integration with TServer process. Additional documentation on advanced ServerMain features will be provided in future updates.
ClientMain
Local methods library executed on each client:
- Runs independently per client
- Pre-instantiated for each client connection
- Access to local display context
- Ideal for UI-specific operations
Library Import/Export
ScriptClasses can be shared between solutions using the Library feature:
Export to Library
- Select ScriptClass in table
- Click Export to Library
- Class is saved to central
Library.dbslnrepository
Import from Library
- When creating new class, select Get from Library
- Browse available classes in Library.dbsln
- Select and import desired class
The Library serves as a centralized repository for reusable components across all your solutions.
Cross-Language Interoperability
FrameworX enables calling between languages transparently:
csharp
// C# ScriptClass calling Python method
double result = @Script.Class.PythonClass.calculate_value(10, 20);python
# Python ScriptClass calling C# method
efficiency = TK.Script.Class.CSharpClass.CalculateEfficiency(95.5, 100.0)For detailed Python/.NET integration including type conversions and limitations, see [Python.NET Integration (Reference)]
Accessing Solution Objects
ScriptClasses can directly access all solution namespaces:
csharp
public void UpdateProduction()
{
// Access Tags
double rate = @Tag.ProductionRate;
// Access Alarms
bool hasAlarm = @Alarm.HasActive("Line1");
// Access Historian
var history = @Historian.GetValues("Temperature", 100);
// Access other Script Classes
var result = @Script.Class.OtherClass.Method();
// Access Script Tasks
@Script.Task.MyTask.Run();
}External References
To use external .NET assemblies:
- Add Assembly Reference
- Go to Scripts → References
- Add external DLL location
- See [Scripts References (Reference)] for details
- Add Namespace Declaration
- Open Code Editor
- Click Namespace Declarations button
- Add namespaces from referenced assembly
- Use in Code
- Call methods from external assembly
- No
usingstatements in code itself
Compilation and Build Order
Build Process
- Classes compile in Build Order sequence (lowest first)
- Cached compilation for unchanged classes
- Full rebuild clears cache
Circular References
Avoid circular references between classes. While not blocked by the system, they cause:
- Compilation failures during full builds
- Maintenance difficulties
- Debugging complications
If circular references exist, temporarily comment one reference to allow compilation.
Best Practices Checklist
- Use descriptive names - Class and method names should indicate purpose
- Add XML comments - Document methods for IntelliSense
- Handle exceptions - Even with automatic protection, validate inputs
- Avoid circular references - Design clear dependency hierarchy
- Use standard classes - Only use Full Namespace when absolutely necessary
- Test incrementally - Verify Build Status after each change
- Use Namespace Declarations - Never put
usingstatements in code
Troubleshooting
Red X Build Status
- Double-click to see specific errors
- Check for missing semicolons or braces
- Verify all referenced tags/objects exist
Methods not accessible
- Confirm Build Status is green
- Check Domain (Server/Client) matches usage location
- Verify syntax:
@Script.Class.ClassName.MethodName()
Class wrapper errors
- Remove any
public classdeclarations - Remove namespace definitions (unless Full Namespace type)
- Remove
usingstatements from code (use Namespace Declarations button)
Cannot find external types
- Add assembly reference in Scripts → References
- Add namespace via Namespace Declarations button
- Verify DLL compatibility with target framework
In this section...