Form-level validation rules

Implicit validation rule checking

An INPUT or INPUT ARRAY block automatically executes form-level validation rules in the following cases:

• The NOT NULL attribute is satisfied if a value is in the field. NOT NULL is checked:
  • when the user moves to a different row in a list controlled by an INPUT ARRAY. However, if the row is temporary and none of the fields is touched, the attribute is ignored.
  • in a DIALOG block, when focus leaves the sub-dialog controlling the field.
  • in a DIALOG block, when NEXT FIELD gives the focus to a field in a different sub-dialog than the current sub-dialog.
  • when the dialog instruction is ended, for example when a procedural DIALOG is ended with ACCEPT DIALOG, or when an singular INPUT is ended with ACCEPT INPUT or with the automatic accept action.
• The REQUIRED attribute is satisfied if the field modification flag is true, if a DEFAULT value is defined, or if the WITHOUT DEFAULTS option is used. REQUIRED is checked:
  • when the user moves to a different row in a list controlled by an INPUT ARRAY. However, if the row is temporary and none of the fields is touched, the attribute is ignored.
  • in a DIALOG block, when focus leaves the sub-dialog controlling the field.
  • in a DIALOG block, when NEXT FIELD gives the focus to a field in a different sub-dialog than the current sub-dialog.
  • when the dialog instruction is ended, for example when a procedural DIALOG is ended with ACCEPT DIALOG, or when a singular INPUT is ended with ACCEPT INPUT or with the automatic accept action.
• The INCLUDE attribute is satisfied if the value is in the list defined by the attribute. INCLUDE is checked when the target program variable must be assigned. This happens:
  • when UNBUFFERED mode is used, focus is in the field, and an action is invoked.
  • when the focus leaves the field.
  • when the user moves to a different row in a list controlled by an INPUT ARRAY. However, if the row is temporary and none of the fields is touched, the attribute is ignored.
  • in a DIALOG block, when focus leaves the sub-dialog controlling the field.
  • in a DIALOG block, when NEXT FIELD gives the focus to a field in a different sub-dialog than the current sub-dialog.
  • when the dialog instruction is ended, for example when a procedural DIALOG is ended with ACCEPT DIALOG, or when a singular INPUT is ended with ACCEPT INPUT or with the automatic accept action.

Performing validation rules explicitly

Singular input dialogs (INPUT / INPUT ARRAY) create default accept / cancel actions. The form-level validation rules are typically performed when the accept action is triggered.

The DIALOG procedural instruction can be used as in singular interactive instructions, with the typical OK / Cancel buttons (accept / cancel actions) to finish the instruction. The accept/cancel action handlers would respectively execute the ACCEPT DIALOG and EXIT DIALOG instructions. This solution allows the user to input or modify one record at a time, and the program flow must reenter theDIALOG instruction to edit or create another record. Alternatively, theDIALOG instruction can let the user input / modify multiple records without leaving the dialog. In this case, you need a way to execute the form-level validation rules defined for each field, before saving the data to the database.

   ON ACTION save 
      IF DIALOG.validate("cust.*") < 0 THEN
         CONTINUE DIALOG
      END IF
      CALL customer_save()

This method automatically displays an error message and registers the next field in case of error. It is mandatory to execute a CONTINUE DIALOG instruction if the function returns an error.

Within singular input dialogs, form-level validation rules can also be explicitly performed with the ACCEPT INPUT instruction, or with the DIALOG.validate("*") API call, followed by a CONTINUE INPUT in case of error.