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 containers' 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 or Option 2
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.