Access Script Entry Points

There are several ways that a script can access its entry points.

An entry point can be a function or a subroutine.

Overall: A script can access entry points in its own script or any of its container's scripts.

Example

You have an object with a script that is looking for entry point xyz.

The entry point is defined in the script for the group that contains the object.

Basic will execute the group's xyz entry point at runtime.

If

You define an entry point (in the scripts) for more than one of the object's containers.

Then

The entry point in the closest container to the object is executed.

Example

You have an object with a script that is looking for entry point abc.

The entry point is defined in the script for the group that contains the object and in the script for the screen.

Basic will execute the group's abc entry point at runtime.

If

You name an object that has a script.

Then

Entry points in that script can be accessed as follows:

  1. Any object on the screen triggers an event.

  2. The event invokes a procedure that has an Invoke Script action with the name of the object.

  3. The script is accessed.

If

You configure a procedure to execute an Invoke script action for a particular entry point and use the <Event trigger object> as the object to look for entry points.

Then

Any object that implements the entry point in its script with the same parameters can use that procedure.

Example

Example

You have two objects.

Each object has its own script with an entry point alpha.

alpha uses one input argument and returns a status

Each alpha procedure does something different.

If you create procedure XYZ to invoke alpha, you can assign it to events for both objects. When the event for the:

  1. First object occurs, the alpha in the first object's script is executed.

  2. Second object occurs, the alpha in the second object's script is executed.

If

Option 1

You configure the global parameter GSM_GLOBAL_SCRIPT to specify the file(s) be loaded at startup.

Multiple script files can be specified by separating them with ";".

The syntax is:

GSM_GLOBAL_SCRIPT|1|c:\scriptpath\script1.bcl;c:\scriptpath\script2.bcl

Where

GSM_GLOBAL_SCRIPT|1| is the global parameter that specifies the file(s) to be loaded at startup.

C:\scriptpath\script1.bcl is the name of the path and script that will be opened..

 

 

Option 2:

You run CimView with the command line option:

/LoadScript scriptFileName

Where

scriptFileName is a file specification) to specify a common script file. (Multiple /LoadScript options can be given on the command line.)

Then

A common script file can be shared among all screens loaded in CimView. Functions that are included in this common file will be loaded when CimView is first run and will be callable as if they were included in the Basic code for the local screen.

If you utilize both options, CimView will load the contents of both files into memory. The functions specified in the GSM_GLOBAL_SCRIPT file will take precedence over those referenced by the /LoadScript option.

If you specify the /LoadScript argument for a file after CimView is already running, its contents will be appended to the list of common functions with the lowest precedence.

More information

1.2. Configure a CimEdit script.