Entering content frame

Controlling the Data Transfer Locate the document in its SAP Library structure

Data is passed from screen fields to ABAP fields with the same names once in each dialog step. If you only use simple module calls, all of the data is transferred in the PAI event before PAI processing starts.

The FIELD statement in the screen flow logic allows you to control the moment at which data is passed from screen fields to their corresponding ABAP fields.

To specify this point, use the following statement in the PAI flow logic:

FIELD f.

Data is not transported from the screen field finto the ABAP field f until the FIELD statement is processed. If a field occurs in more than one FIELD statement, its value is passed to the program when the first of the statements is reached.

Only screen fields that do not appear in a FIELDS statement are transferred at the beginning of the PAI event. Do not use fields in PAI modules until they have been passed to the program from the screen. Otherwise the ABAP field will contain the same value as at the end of the previous dialog step.

The exception to this are fields that were initial in the PBO event and are not changed by the user. These are not transported by the FIELD statement. If a field of this type is filled with a value in a PAI module before its corresponding FIELDstatement is executed, any value that you assign to it is not overwritten.

The FIELD statement together with the MODULE statement has further functions in connection with conditional module calls  and validity checks .

Example

Controlling the data transfer

PROGRAM demo_dynpro_field.

DATA: ok_code TYPE sy-ucomm,
      save_ok LIKE ok_code,
      box1(1) TYPE c, box2(1) TYPE c, box3(1) TYPE c, box4(1) TYPE c,
      mod1_result1(1) TYPE c, mod1_result2(1) TYPE c,
      mod1_result3(1) TYPE c, mod1_result4(1) TYPE c,
      mod2_result1(1) TYPE c, mod2_result2(1) TYPE c,
      mod2_result3(1) TYPE c, mod2_result4(1) TYPE c,
      mod3_result1(1) TYPE c, mod3_result2(1) TYPE c,
      mod3_result3(1) TYPE c, mod3_result4(1) TYPE c.

CALL SCREEN 100.

MODULE init_screen_100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  CLEAR:  box1, box2, box3, box4.
ENDMODULE.

MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'CANCEL'.
    LEAVE PROGRAM.
  ENDIF.
ENDMODULE.

MODULE module_1 INPUT.
  mod1_result1 = box1.
  mod1_result2 = box2.
  mod1_result3 = box3.
  mod1_result4 = box4.
ENDMODULE.

MODULE module_2 INPUT.
  mod2_result1 = box1.
  mod2_result2 = box2.
  mod2_result3 = box3.
  mod2_result4 = box4.
ENDMODULE.

MODULE module_3 INPUT.
  mod3_result1 = box1.
  mod3_result2 = box2.
  
mod3_result3 = box3.
  mod3_result4 = box4.
ENDMODULE.

The next screen (statically defined) for screen 100 is 100. It has the following layout:

This graphic is explained in the accompanying text

The screen fields box1, box2, box3and box4are assigned to the checkboxes on the left that are ready for input.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.
  MODULE init_screen_100.

PROCESS AFTER INPUT.
  MODULE user_command_0100.
  MODULE module_1.
  FIELD box2.

  MODULE module_2.
  FIELD: box1, box3.

  
MODULE module_3.

In the GUI status STATUS_100, the icon This graphic is explained in the accompanying text (F12) is active with function code CANCEL.

When the user selects the checkboxes and chooses ENTER to trigger the PAI event, the output fields show the dialog modules in which each screen field is available.

If all of the checkboxes are selected, the result is:

This graphic is explained in the accompanying text

         The screen field box4 is transported in the PAI event, since it does not occur in any FIELDstatements.

         box2 is not transported until before the dialog module module_2, and is therefore not available in user_command_0100 und module_1.

         box1 and box3 are transported before dialog module module_3, and are therefore only available in that module.

 

 

 

Leaving content frame