Triggers are FlashBASIC subroutines that accept one argument called when an operation is performed on a record or a table. Persistent data can be stored using named commons. Some information about the context in which the trigger is called is obtained by either using the FlashBASIC access() function or using predefined environment variables.
NOTE |
|
The following trigger is available in the VME only:
Processing Code |
Description |
Calls a FlashBASIC subroutine from the file-defining item. If the processing code is on the correlative, it is called when an item is filed from the Update Processor. If the processing code is on the input conversion, it is called before the item is displayed in the Update Processor. Called subroutines are Flash compiled to improve performance. |
The following triggers are available in the FSI only:
Processing Code |
Description |
The callc (close) trigger is called before the table is closed. |
|
The calld (delete file) trigger is called before the file is deleted. |
|
The calle (clear file) trigger is called before the file is cleared. |
|
The callr (read) trigger is called when a record is read from the table. |
The following triggers are available in both the VME and FSI:
Processing Code |
Description |
The callo (open) trigger is called after a table has successfully been opened. |
|
The callx (write) trigger is called when a record is updated in the table. |
Once the code for a trigger has been loaded in memory, it stays in memory as long as the files that use it remain open. If the trigger code needs to be recompiled, all files using the trigger must be closed. This often requires that VME users log off the system and exit VB applications. This behavior can be modified using the Load Trigger at Each File Open option from the FlashBASIC tab of the D3 File Manager (see the D3 System Administration Guide for more information).
A trigger should not normally interact with the user. However, if a module does some terminal I/Os (for debugging purposes, for example), or drops in the debugger, some terminal I/Os are possible.
If a local VME process does the file operation, the terminal I/Os are routed to the user’s display terminal.
If the file operation is done by a remote client (VB, D3 File Manager, remote VME), a Telnet session is created on the server and remains open as long as file operations are being done. It can be closed at any time.
NOTE |
If there is more than one Telnet session open for remote file access, there is no guarantee of ensuring what the terminal I/Os by a given trigger will do to a given Telnet session. |
The creation of the Telnet client can be disabled by deselecting the Automatic Input/Output Using Telnet check box in the FlashBASIC tab of the D3 Device Manager.
Triggers can use these classic VME resources: execute, iconv, oconv. All others, such as procread, procwrite, tclread, abort the trigger.
NOTE |
Using VME resources from triggers is not recommended because of the high cost of these operations. |
When a trigger is run, the current account is the account where the file is located, not where the user might be, unless the trigger is invoked by a user running in the VME. In this case, the account is the current user’s account. This is especially important when opening files in triggers. If the file is not in the same account as the file on which the operation is performed, an explicit path must be used.
NOTE |
If the trigger calls external subroutines, either use an explicit path name or add the subroutine to the Domain Catalog. |
Processing Code Supported in Triggers on D3 Windows
The following processing codes are supported in triggers on D3 Windows when using oconv and iconv functions: G, MC, MD, ML and MR. Using any other processing code may return unpredictable results.
The following topics are presented in this section:
Describes how to insert a trigger. |
|
Describes how to recompile a trigger. |
|
Describes the use of named commons in triggers. |
|
Describes the use of variables in triggers. |