Some examples of the functionality of event PROCESS AFTER INPUT, also the statements MODULE, FIELD and CHAIN are covered.

• checking entered field values (calling error messages, start calculations, search in the database whether the entered value does actually exist, ...)
• catching menu actions, and starting related functions
• processing data entered

The system variable SY-DATAR indicates whether something has been changed in the fields contents of the screen. This could be useful in the program, e.g. to determine if it's necessary to save the transaction data. Checking single fields can be done with the .. ON REQUEST option of FIELD .. MODULE ..

Example: An example of PAI implementation

The system variable SY-DATAR indicates whether something has been changed in the fields contents of the screen. This could be useful in the program, e.g. to determine if it's necessary to save the transaction data. Checking single fields can be done with the .. ON REQUEST option of FIELD .. MODULE ..

 *--------------------------------------- 
 * MODULE: CHANGE_CHECKER INPUT.
 *--------------------------------------- 
 * Checking if anything (any field) was 
 * changed in the screen
 *--------------------------------------- 
 MODULE CHANGE_CHECKER INPUT.
 
   IF SY-DATAR EQ 'X'. "Flag : input recieved ?
     ANYTHING_CHANGED = 'X'.
   ENDIF.
 
 ENDMODULE.

A very important PAI module: catching the end users MENU_RESPONS:

 *-----------------------------------------------------------------------
 * MODULE: D1310_MENU_RESPONS
 *-----------------------------------------------------------------------
 * Responding to the end users menu-action
 *-----------------------------------------------------------------------
 MODULE D1310_MENU_RESPONS INPUT.
   OK-COPY = OK-CODE. "Good trick to prevent a ...
   CLEAR OK-CODE.	  " repeating action selection
   CASE OK-COPY.
     WHEN SPACE.	  "Special actions on empty OK-CODE ?
     WHEN 'QUIT'.	  "Quit (connected to F12 in menu painter)
       LEAVE TO SCREEN 900.	 "Go to DYNPRO 900
     WHEN 'HNDL'.     "Perform: HANDLE_IT
       PERFORM HANDLE_IT.
   ENDCASE.
 
 ENDMODULE.

Note: the OK-CODE should always be cleared to make sure the choosen action won't be repeated in the currently active screen, or initiate another function in a follow up-screen.

The MODULE statement

Modules are the ABAP routines that can be called in the DYNPRO flow logic. They are built like any other FORM-routine, except the use of USING and CHANGING (and TABLES) is not possible. Some guidelines:

• A module starts with MODULE <name> OUTPUT or MODULE <name> INPUT. PBO modules are indicated with OUTPUT (before), PAI modules by INPUT(after).
• The end of a module: ENDMODULE
• All ABAP statements are valid for modules
• (Thus) FORM routines can be called from modules.

Throwing an error MESSAGE from a MODULE

The flow logic can indicate that a certain field entry is not accepted. This is done from the ABAP that calls a MODULE. Method: The ABAP initiates an ERROR message with the MESSAGE statement, for example MESSAGE E999 WITH 'You did wrong, don''t do that again'. The DYNPRO's behaviour can be controlled with this statement.

The FIELD statement

An important part of the screen is a of course a field. When processing from ABAP it is possible to check a field's contents. If a MODULE is created to check the field, this MODULE can be linked to the field in the DYNPRO with the statement FIELDin the flow logic of a DYNPRO. Syntax:

FIELD TABNAME-FIELDNAME MODULE D1310_FIELDNAME.

If MODULE D1100_KUNNR initiates an E-message, the end-user can correct the contents so that the error is solved. But there's more to the FIELDstatement, check out the on-line help system for the other options.

An example of a field check, try it out and watch what happens with the screen when the value '123' is entered for TABNAME-FIELDNAME.

*-------------------------------------
* MODULE: D1310_FIELDNAME INPUT.
*-------------------------------------
* Check: the value of FIELDNAME from
* table TABNAME may not equal '123'.
*-------------------------------------
MODULE D1310_FIELDNAME INPUT.
  IF TABNAME-FIELDNAME EQ '123'.
    MESSAGE E999.
  ENDIF.
ENDMODULE.

The CHAIN statement

With the statements CHAIN and ENDCHAIN in the flow logic of a DYNPRO, fields can be grouped together. In practice is possible that not just one field but a combination of fields lead to an error. E.g. if a header and position are the input fields, the values entered could be a legal header and a legal position. But the combination could be wrong. If a MODULE within a CHAIN .. ENDCHAIN kicks off an E-message, the end-user can adjust all the fields within the CHAINto solve the problem.

An example of PBO PAI implementation with FIELD and CHAINimplemented.

*-------------------------------------
PROCESS BEFORE OUTPUT.
*-------------------------------------
  MODULE D1310_INIT. "Called before screen-display
  *-------------------------------------
  PROCESS AFTER INPUT.
  *-------------------------------------
  * The fields within the chain will be regarded as one
  CHAIN.
    FIELD MATNR_FROM MODULE D1310_MATNR_FROM.
    FIELD MATNR_TO MODULE D1310_MATNR_TO.
    FIELD ZTRM-TRMSRT MODULE D1310_TRMSRT.
  ENDCHAIN.
  MODULE D1310_CALCULATION. "Calculate stuff
  MODULE D1310_MENU_RESPONS."Catch the end user's action 

• Prev
• Next