Userexits at Masks
You can apply mask userexits in order to
- prepare masks of your application for being worked with by the users,
- automatically execute program functions while editing data within a mask, or
- manipulate or check data before or after the final data base transaction.
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.