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.

Related Topics