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.
For D3 Windows in the VME, or on UNIX, flash compiling triggers is recommended.
For D3 Windows in the FSI, triggers MUST be flash compiled. A trigger on an FSI file cannot reference a flashed subroutine in a VME account.
The following trigger is available in the VME only:
| Processing Code | Description |
|---|---|
| call processing code | 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 |
|---|---|
| callc (close trigger) processing code | The callc (close) trigger is called before the table is closed. |
| calld (Delete Trigger) processing code | The calld (delete file) trigger is called before the file is deleted. |
| calle (clear trigger) processing code | The calle (clear file) trigger is called before the file is cleared. |
| callr (Read Trigger) processing code | 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 |
|---|---|
| callo (open trigger) processing code | The callo (open) trigger is called after a table has successfully been opened. |
| callx (write trigger) processing code | 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.
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.
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.
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.