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.