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.
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. |
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. |
callr (Read Trigger) processing code | The callr (read) trigger is called when a record is read from the table. |
callx (write trigger) processing code | The callx (write) trigger is called when a record is updated in the table. |
After 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.
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.
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.