Show TOC

Calling Modules UnconditionallyLocate this document in the navigation structure

Use

In the PAI event, the PAI modules are called in the sequence in which they occur in the dynpro flow logic, after the automatic field checks. This means that the input on the dynpro must satisfy the automatic checks before the first module can be called. In particular, all required fields must be filled, and any checks against value lists or check tables defined for the field in ABAP Dictionary must be successful.

In some cases, the user may have to enter a considerable amount of data merely in order to be able to leave the screen. To prevent this, special function codes can be combined with a special module call. The corresponding module is called independently of the user inputs.

Type E Function Codes

The function codes for dynpros and the GUI status can be given type E. For this purpose, the Function Type attribute in Screen Painter is set to E for the screen elements of the dynpro concerned. For GUI status functions, choose Start of the navigation path Goto Next navigation step Object Lists Next navigation step Function List End of the navigation path in Menu Painter, select the required function codes, and enter E for the Function Type.

If the user chooses a screen element or a user interface element with a function code of type E, the system bypasses the automatic field checks and calls a special module in the dynpro flow logic. If the special module call does not exist, the system resumes normal PAI processing, that is, the automatic field checks take place after all.

As a rule, type E functions should allow the user to leave the screen. Consequently, the function codes for the icons F3, Shift+F3, and F12 in the toolbar for the GUI status usually have type E.

Calling a Module for Type E Function Codes

When the user chooses a function with type E, the dynpro flow logic jumps directly to the following statement:

MODULE mod AT EXIT-COMMAND.

Regardless of where it occurs in the dynpro flow logic, this statement is executed immediately, and before the automatic checks for the field contents on the screen. Before the module mod is executed, only the contents of the OK code field are transported to the ABAP field with the same name. However, no other dynpro fields are transported. If there is more than one MODULE statement with the AT EXIT- COMMAND addition, only the first is executed. If there are no MODULE statements with the AT EXIT- COMMAND statement, normal PAI processing resumes.

If the user chooses a function whose function code does not have type E, the MODULE <mod> AT EXIT-COMMAND statement is not executed.

Modules for Type E Function Codes

The MODULE... AT EXIT-COMMAND statement is normally used to leave the current dynpro without the automatic input checks taking place. It should therefore be programmed to contain an appropriate variant of the LEAVE statement, to exit the current screen, the call chain, or the entire program, as appropriate. If the module does not exit the dynpro, normal PAI processing resumes after it has finished, that is, the automatic field checks take place, and the normal PAI modules are called, with data being transported from the dynpro back to the program in the order defined in the FIELDS statements.

Unconditional module call





PROGRAM demo_dynpro_at_exit_command.
DATA: ok_code TYPE sy-ucomm,
      save_ok LIKE ok_code,
      input1(20) TYPE c, input2(20) TYPE c.
CALL SCREEN 100.
MODULE init_screen_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.
MODULE cancel INPUT.
  MESSAGE i888(sabapdocu) WITH text-001 ok_code input1 input2.
  IF ok_code = 'CANCEL'.
    CLEAR ok_code.
    LEAVE PROGRAM.
  ENDIF.
ENDMODULE.
MODULE back INPUT.
  MESSAGE i888(sabapdocu) WITH text-002 ok_code input1 input2.
  IF ok_code = 'BACK' OR ok_code = 'EXIT'.
    CLEAR: ok_code, input1, input2.
    LEAVE TO SCREEN 100.
  ENDIF.
ENDMODULE.
MODULE execute1 INPUT.
  MESSAGE i888(sabapdocu) WITH text-003 ok_code input1 input2.
  save_ok = ok_code.
  CLEAR ok_code.
ENDMODULE.
MODULE execute2 INPUT.
  MESSAGE i888(sabapdocu) WITH text-004 ok_code input1 input2.
  IF save_ok = 'EXECUTE'.
    MESSAGE s888(sabapdocu) WITH text-005.
  ENDIF.
ENDMODULE.

The static next dynpro number of dynpro 100 is 100. It has the following layout:

The dynpro fields input1 to input2 are assigned to the input fields. The input fields are marked in their attributes as required fields. The function codes of the pushbuttons are EXECUTE and CANCEL. CANCEL has function type E.

In the GUI status STATUS_100, the F3 and F12 icons are activated with the function codes BACK and CANCEL respectively. Both have function type E. Function key F8 is still assigned to the EXECUTE function code. EXECUTE does not have function type E.

The screen flow logic is as follows:



PROCESS BEFORE OUTPUT.
  MODULE init_screen_0100.
PROCESS AFTER INPUT.
  MODULE execute1.
  MODULE cancel AT EXIT-COMMAND.
  MODULE back AT EXIT-COMMAND.
  MODULE execute2.

The program uses information and status messages to show which modules are called following user interaction and which data is transported.

  • If the user chooses Execute without filling out the mandatory fields, the automatic field check displays an error message.

  • If the user fills out the mandatory fields and then chooses Execute, all of the dynpro fields are transported to the program, and the modules execute1 and execute2 are called.

  • If the user chooses Cancel, the OK_CODE field is transported and the cancel module is called, regardless of whether the user filled out the mandatory fields. The program is exited at this point.

  • If the user chooses Back, the OK_CODE field is transported and the cancel module is called, regardless of whether the user filled out the mandatory fields. However, the program is not exited, since the function code is BACK. Instead, the automatic field checks are performed. If the mandatory fields are filled, the modules execute1 and execute2 are called.

The back module is never called. Two module calls using AT EXIT-COMMAND do not make any sense in the dynpro flow logic. In the above example, the function code BACK should also be processed in the cancel module. Then the position of the module statement with AT EXIT-COMMAND is irrelevant.