Userexits at Masks

You can apply mask userexits in order to

DataView provides six triggers for calling userexits at masks. There are divided into:

mask triggers:
pre_mask-trigger, post_mask-trigger

action trigger:
edit_action-trigger, select_action-trigger, pre_action-trigger, post_action-trigger

While you use userexits at mask triggers to activate program functions that initiate actions at opening or closing the mask, the userexits at the action triggers always refer to the records manipulated by select-, edit-, query-, or delete operations.


Mask Triggers

pre_mask-trigger
You invoke a mask userexit at the pre_mask-trigger if you want to prepare a mask for displaying on the screen. For example you can call the standard userexit dal_wdh_upd_lis to simply fill a list with records immediately after opening the widget. You can also use your own userexits to hide records in a mask from unprivileged users or to calculate and enter values for data-base-independent fields.

post_mask-trigger
You invoke a mask userexit at the post_mask-trigger if you want to execute functions immediately after closing the mask. You can activate other masks or delete related masks (e.g. a mask with relation data, opened at the record of a master data mask).


Action Triggers

All action triggers are record-related. i.e. if several records are effected by one manipulation, the action triggers are passed several times.

edit_action-trigger
You call a mask userexit at the edit_action-trigger if you want to execute functions in the mask immediately before edit or query operations. The edit_action-trigger becomes active if the user - via function menus at the widget or via keyboard functions - initiates edit or query functions that put the mask into insert-, update-, or query-mode of mask edit state. For instance, when creating new records you can make sure that the number field is automatically filled or that copy operations of records within a mask are prevented.

select_action-trigger
With the aid of the select-action-trigger, you can implement some record-dependent functionality. The trigger passes a parameter to userexits identifying the record which was selected or de-selected in a form, the record last scrolled into the form fields (i.e. currently visible). In addition it is possible to register doubleclick records.

Example: parameter passing in lists:
+7 = Seventh record selected
-7 = Seventh record de-selected
++7 = Doubleclick on seventh record, not yet selected
--7 = Doubleclick on seventh record, already selected
+0 = All records selected
-0 = All records de-selected

Example: parameter passing in forms:
+7 = Seventh record displayed in form
++7 = Doubleclick on a field of the seventh visible record
-0 = No record displayed
Negative numbers -n to -1 do not appear

With the standard userexit dal_cch_set_tit at the sel_action trigger, for instance, it is possible to display graphics (bitmaps) depending on the active record. With the standard userexit dal_cch_sel_dtv records can be updated when doubleclick the record.

pre_action-trigger
You call a mask userexit at the pre_action-trigger if you want to check or complete edited or newly created records, before you accept them into the data base. The pre_action-trigger becomes active when the user confirms a edit-, query-, or delete operation within the active mask. For instance when editing you can check the field contents of several fields for logical consistency or automatically generate the content of empty fields. In case of queries you can manage or complete search criteria at the pre_action-trigger. For instance you can reject illogical combinations of search terms or check search criteria for whether they can produce any useful results. When deleting records a userexit at the pre_action-trigger can check whether deleting is allowed. For instance you can check whether the record to be deleted has any relation to other records or whether the current user has any privileges for deleting data.

post_action-trigger
You call a mask userexit at the post_action-trigger if you want to initiate actions after the data base transaction itself. The post_action-trigger becomes active after the user has confirmed an edit-, query-, or delete operation in a mask and DataView has executed the transaction successfully. For instance you can execute manipulations in other tables which are not covered by the general mask definition. Releasing data in external tables would be a typical example.

In Query mode communication between the server and client is discontinued as long as a Post_Action userexit is being executed. All changes to data in the mask are not treated as individual actions, but are combined in a summarised action together with the transmission of the results data. This has the consequence that changes to the mask layout (e.g. change visibility of fields) cannot be transmitted to the client end, thus, the call of such functions in the Post_Action trigger is illegal.