Get Example source ABAP code based on a different SAP table
ABAP_DYNPRO - Input Checks in Dialog Modules Input checks in PAI modules are enabled by first transporting the content of the input fields to the ABAP program. This is where the content can then be checked. Any errors can be corrected on the screen before further modules are called. This is achieved by combining the statements FIELD and CHAIN of the dynpro flow logic with messages. ITOC
Checking Single Fields If a warning or error message is sent in a module mod whose call is combined with a FIELD statement FIELD f MODULE mod. the input field in question becomes the only input-enabled field on the current dynpro and the input can be repeated. If the field is only checked once, PAI resumes directly after the FIELD statement, and the preceding modules are not called again.
Checking Multiple Fields If a warning or error message is sent in a module mod1, mod2, ... whose call takes place in a processing chain CHAIN. FIELD: f1, f2,... MODULE mod1. FIELD: g1, g2,... MODULE mod2. ... ENDCHAIN. the input fields of all dynpro fields in the processing chain become input-enabled on the current dynpro. This includes fields after the MODULE statement in FIELD statements. None of the other fields are input-enabled. Even when a MODULE statement is combined with a FIELD statement within a processing chain, all input fields in the chain become input-enabled and not just the field in question. If the fields in the processing chain are only checked once, PAI resumes directly after the CHAIN statement, and the preceding modules are not called again.
Defining Input-Enabled Fields and Data Transport In the case of warnings and error messages, a FIELD statement outside of a processing chain defines whether a single field is input-enabled. FIELD statements between CHAIN - ENDCHAIN, on the other hand, define whether multiple fields are input-enabled. Here, all fields linked using FIELD are transported back to the screen layout without PBO processing taking place. This ensures that any changes to the field content are displayed before a message. This also applies to the sending of information messages, but no fields are input-enabled.
Checking Fields Repeatedly It may be necessary to specify a single dynpro field in multiple FIELD or CHAIN statements. If an associated dialog module sends a warning or error message, PAI resumes after the user enters a new value. It is not possible to resume at the associated FIELD or CHAIN statement if the error field is also specified in an earlier FIELD or CHAIN statement. Instead, all FIELD and CHAIN statements containing the error field must be repeated. PAI processing resumes at the first FIELD or CHAIN statement containing one or more of the fields in the FIELD or CHAIN statement in which the error occurred and which were modified the last time the screen layout was displayed.
Other Functions in the <(>FIELD<)> and <(>CHAIN<)> Statements All functions of the statements FIELD and CHAIN used to defined data transport and for conditional module calls are also available in combination with warnings and error messages. The content of each field is transported after the FIELD statement in question. A warning or error message in a conditional module in a processing chain makes all fields in the chain input-enabled, although not all fields need to be transported. If warnings or error messages are sent in dialog modules that are not linked with fields using FIELD or CHAIN, no dynpro fields become input-enabled. This makes a termination necessary, which itself requires a corresponding unconditional module call.
ABAP_EXAMPLE_ABEXA Input Checks in Dialog Modules ABAP_EXAMPLE_END
