Triggers at Masks

Each mask created in DataView provides six triggers. These triggers are used for the program-controlled call off userexits when you work with masks. You can use them for instance to prepare masks for editing, to check data during editing, or to influence closing database transactions. There are mask triggers and action triggers.


Mask Triggers

You control the opening and closing behavior of a mask by calling userexits at mask triggers.

Trigger Trigger Moment Fields for Userexit Call Suitable Standard Userexits
Pre_Mask-Trigger after calling the mask, but before it is displayed on the screen Pre_Mask Userexit in the mask master -> Standard mask userexits,
-> Universally usable standard userexits
Post_Mask-Trigger after closing the mask Nach-Maske-Userexit in the mask master

Any required application parameter is can be added to the userexit entry separated by spaces. There is no separate parameter field. The total entry (userexit and parameter string) may not be longer than 255 characters.

Pre_Mask Trigger
You invoke a mask userexit at the pre_mask-trigger, if you want to prepare a mask before it is displayed on the screen. The userexit wdh_upd_lis, for instance, can be easily used to make sure that a list is filled with records immediately after opening the list. You can also use self-programmed userexits to hide data fields within a mask from unprivileged users.

Post_Mask Trigger
You invoke a mask userexit at the post_mask-trigger, if you want to execute functions directly after closing the mask. For instance you could define an inflexible program flow for entering data either by automatically opening mask 2 after closing mask 1 or by writing a message informing the user about the fact that further data have to be entered in further masks.


Action Triggers

By calling userexits at action triggers you control the behavior if data are changed in masks (query, idiot, or delete operations). All action triggers are record-related, i.e. if several records are subject to changes, the action triggers on passed several times.

Trigger Trigger Moment Fields for Userexit Call Suitable Standard Userexits
Select_Action-Trigger In lists: after double-click on records or after selecting or deselecting records for each individual record; only once after global selecting or deselecting
In forms: when records are scrolled
Sel.-Action userexit in the mask master -> Standard mask userexits,
-> Universally usable standard userexits
Edit_Action-Trigger Prior to edit or query operations in the mask Edit-Action userexit in the mask master
Pre_Action-Trigger When confirming edit, query, or delete operations in the mask, but prior to the corresponding database transaction Pre_Action userexit in the mask master
Post_Action-Trigger When confirming edit, query, or delete operations in the mask, but after the corresponding database transaction Post_Action userexit in the mask master

Any required application parameter is can be added to the userexit entry separated by spaces. There is no separate parameter field. The total entry (userexit and parameter string) may not be longer than 255 characters.

In addition to any application parameters passed, all action triggers internally pass a default parameter to the installed userexit. In case of Edit_, Pre_, and Post_Action triggers this parameter contains information about the current working mode of mask-edit state and the current row position. In case of the Select_Action trigger it contains information about the currently selected or deselected record or about the record on which a mouse double-click has been executed. By evaluating the default parameter you can react on the current program situation in your own userexits. Details on that can be found in -> Programming Interface, section Userexits with Default- and Application Parameters. There you also find information about the structure of the default parameter and how it can be evaluated.

Select_Action Trigger
The Select_Action trigger evaluates mouse clicks or scroll actions on records. The trigger moment is different for lists and forms.
Attention! In the Java Client the select_action_trigger for scroll actions works only for forms.

In lists it is after a single mouse click (selecting or deselecting) or after a double-click on the record individually for each record. The global selecting / deselecting is an exception, because here the trigger works only once. Please observe that the trigger also works after storing or cancelling, because selected records are deselected.

Attention! When you select/deselect records in lists, DataView version 4.1- or higher does not send any events to the DataView server any longer. For this reason the Select-Action trigger only works in lists when you double-click records. In order to secure compatibility, the new behavior can be controlled with the help of the new client variable DATAVIEW_SACT. The setting ON provides the traditional functionality for old applications, while OFF reduces network load (recommended).

In forms it works after scrolling records in the form or after a double-click on one of the form fields. Please observe that the trigger also works give an empty form is filled (reconfigure, get), because this scrolls to the first record.

Suitable standard userexits to be called at the Select_Action trigger are for instance cch_set_tit, to display graphics record-independently in a form or cch_sel_dtv, to immediately edit records after a mouse double-click.

Edit_Action Trigger
You invoke a mask userexit at the edit_action-trigger, if you want to execute functions immediately before editing- or search operations in the mask. The edit_action-trigger becomes active if the user initiates edit or search operations via menu/button or via keyboard events, which set the mask into insert, update, or query mode of mask edit state. For instance you could automatically assign number fields when new records are created.

Pre_Action-Trigger
You invoke a mask userexit at the pre_action-trigger, if you want to check or complete edited or newly created records in a mask, before they are accepted to the data base. The pre_action-trigger becomes active if the user confirms edit, search, or delete operations in the mask. For instance you could check the content of several fields for logical consistency or automatically fill empty fields.

Post_Action-Trigger
You invoke a mask userexit as post_action-trigger, if you want to initiate functions after the actual data base transaction. The post_action-trigger becomes active, after the user confirmed an edit, search, or delete operation in the mask and DataView successfully executed the transaction. For instance you can start manipulations other tables which are not covered by the general mask definition or you can calculate and enter data base independent fields. A typical example is releasing data in external tables.