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