trigger leaveModifiedKey
Location for ProcScript that determines what happens after a key (especially a compound key) of an occurrence is modified. Applicable only in form components.
Declaration: | trigger
leaveModifiedKey
|
Applies to: | Entity in Form component |
Activation: | Activated when a primary key or candidate key field has been modified, and the user moves the cursor to a non-key field. For details, see Trigger Activation. |
Default behavior: | None. |
Behavior upon completion: | If $status is less
than 0, the user cannot leave the current primary or candidate key field. When the user tries to leave the key field, the rescheduling of the leaveModifiedKey is based on the previous result of the retrieve/o statement in the trigger. If retrieve/o returned a non-negative value, even if the return value in $status was less than 0 and the user could not leave the key field, the trigger will not be activated again. |
Description
This trigger is particularly useful when working with compound keys. The trigger is only activated when the cursor is moved out of the compound key, not when the cursor is moved from one field in the key to another.
The leaveModifiedKey trigger is one a group of triggers (which includes loseFocus, and leaveModified) that work in combination with the validation triggers to handle all the processing that should take place when a user modifies the active path. In general, these triggers are used for user interface and calculation functionality; the validation triggers are intended to handle data validation and error trapping.
Trigger Activation
This trigger is activated when a primary key or
candidate key field has been modified, and the user moves the cursor to a non-key field. For
candidate keys, the trigger is activate only if the Validate property is
True
. It is not activated by modifications to foreign keys or indexes
(unless they form part of the primary or candidate key).
The trigger is not activated if profile characters are used in one of the primary key or candidate key fields.
Before the trigger is activated, the following conditions must also be true:
- The field-level validate and loseFocus triggers for the current field completed successfully (did not return a negative value).
- The next field (taking account of Previous or Next mode) is not part of the current primary or candidate key. The next field is the field that would be next if the prompting sequence were default, that is, the field that would be next if the nect and previous triggers were empty. For more information, see Next Field.
- All the key fields contain data, or any empty
fields have been defined as
LEN(0-0)
, that is, any empty fields are defined as optional. (See below for more information.) - All the key fields pass the syntax checks defined for them.
- The validateKey trigger completed successfully.
It is possible to force this trigger to be activated using the ProcScript statement set$keycheck.
Next Field
The following events always make the structure editor assume that the next field is not a primary or candidate key field:
-
The user moves the cursor with one of the following structure editor functions:
- ^ACCEPT
- ^STORE
- ^ADD_OCC
- ^INS_OCC
- ^NEXT_OCC
- ^PREV_OCC
-
The user uses a cursor key to move the cursor out of the current occurrence.
-
One of the following ProcScript statements is executed:
- setocc
- store
- $prompt to a non-key field
Empty Key Fields
Normally, a field in a compound key is mandatory,
that is, it cannot be empty and must contain data. However, if the field syntax of such a field is
LEN(0-0)
, the field is considered optional and is allowed to be empty.
Consider an entity with a compound primary key:
- The primary key consists of three fields: PK1, PK2, and PK3
- The user has entered values in fields PK1 and PK3, but has left the field PK2 empty.
Activation of the leaveModifiedKey trigger depends on the definition of the empty field PK2. Normally, the leaveModifiedKey trigger is not fired in this case.
However, if the empty field PK2 has been defined
as LEN(0-0)
, the leaveModifiedKey trigger
is fired.
Uniface considers the primary key to be complete and, because the user has entered data in fields PK1 and PK3 (and therefore modified them), Uniface activates the leaveModifiedKey trigger.