# FlashBASIC triggers

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:

- 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. |
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.

- 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, and
 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 codes 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

- MR

Using any other processing code might return unpredictable results.

---
Source: https://d3codex.com/pickbasic-flashbasic/flashbasic-triggers/ - part of the D3Codex reference.