Processing Input/Output Fields
Use
Input/output fields are either conventional fields in which the user can enter values using the keyboard or by selecting from a value list, or checkboxes or radio buttons, for which the mouse is required. All input/output fields have a name that associates them with a dynpro field. The data type of the dynpro field determines the input format. For example, letters cannot be entered in an input field with a numeric type. The dynpro detects invalid values automatically. Radio buttons and checkboxes always have the data type char and length 1. A selected radio button or checkbox both fill the associated dynpro field with the value 'X', if not selected with space.
The ABAP program must contain identically named data objects that match the dynpro fields exactly, otherwise data may be lost (see Associating ABAP Strings with Dynpro Fields). The ABAP fields for checkboxes and radio buttons must have the type c and length one.
After the PBO event is processed, the dynpro fields are filled with the values from the ABAP fields. Before or during the PAI event, the values from the dynpro fields are written to the ABAP fields. Only one radio button within a group can be selected at a time. If more than one of the associated fields contains the value 'X', the program terminates.
The following procedure ensures that dynpro fields and ABAP fields always match:
Local Program Fields
If input/output fields are to be used in one program only, the fields should be declared in the ABAP program first (except for checkboxes and radio buttons), then the program activated, and finally the fields applied from the ABAP program to the dynpro in Screen Painter. From now on, however, the fields must not be changed in the ABAP program.
Dynpro Fields with Dictionary Reference
If input/output fields are required in more than one program and information from the ABAP Dictionary is required, such as field labels, field helps, and input helps, the corresponding fields should be applied from ABAP Dictionary. Both flat structures and database tables can be referenced here.
The identically named fields must then be declared as an interface work area in the ABAP program using the statement TABLES. Declaring an identically named field using a TYPES reference to the data type in ABAP Dictionary is not enough for the data to be passed between the dynpro and the ABAP program.
To avoid naming conflicts between dynpro fields, internal work areas in programs, and database tables, it is often best to define a separate ABAP Dictionary structure for dynpros, containing all of the required input/output fields to be used for one or more dynpros of a program or of a whole package. The work areas declared using TABLES in the ABAP program then function exclusively as an interface between the program and the dynpro. If necessary, values can be assigned to the interface work area and back.
The advantage of referring to ABAP Dictionary data types is that both the dynpro fields and the fields in the ABAP program are updated automatically if the data type changes.
Local program fields
PROGRAM demo_dynpro_input_output.
DATA: input TYPE i,
output TYPE i,
radio1(1) TYPE c, radio2(1) TYPE c, radio3(1) TYPE c,
box1(1) TYPE c, box2(1) TYPE c, box3(1) TYPE c, exit(1) TYPE c.
CALL SCREEN 100.
MODULE init_screen_100 output.
CLEAR input.
radio1 = 'X'.
CLEAR: radio2, radio3.
ENDMODULE.
MODULE user_command_0100 input.
output = input.
box1 = radio1.
box2 = radio2.
box3 = radio3.
IF exit NE space.
LEAVE PROGRAM.
ENDIF.
ENDMODULE.
The static next dynpro number of dynpro 100 is 100. It has the following layout:
The part of the element list relevant for the dynpro fields is as follows:
|
Name |
Type |
defLg |
Format |
|
input |
I/O |
9 |
INT4 |
|
output |
I/O |
11 |
INT4 |
|
radio1 |
Radio |
1 |
CHAR |
|
box1 |
Check |
1 |
CHAR |
|
radio2 |
Radio |
1 |
CHAR |
|
box2 |
Check |
1 |
CHAR |
|
radio3 |
Radio |
1 |
CHAR |
|
box3 |
Check |
1 |
CHAR |
|
exit |
Check |
1 |
CHAR |
|
OK |
20 |
OK |
In Screen Painter, the screen fields output, box1, box2, and box3 are deactivated.
The length of input is such that the user can enter a nine-digit integer without thousand separators. However, the display in the output field contains up to two thousand separators. If the length of input were to remain 11 digits, a runtime error could occur if users do not set thousand separators.
The screen flow logic is as follows:
PROCESS BEFORE output.
MODULE init_screen_100.
PROCESS AFTER input.
MODULE user_command_0100.
The entries in the input fields are passed to the ABAP program in the PAI event, and assigned to the output fields in the dialog module USER_COMMAND_100. The next time the dynpro appears, the output fields contain the appropriate values. The input fields are set in the PBO dialog module init_screen_100. If the user selects the dynpro field exit (value 'X'), the program ends.
Dynpro fields with dictionary reference
PROGRAM demo_dynpro_dictionary.
TABLES demo_conn.
DATA wa_spfli TYPE spfli.
CALL SCREEN 100.
MODULE init_screen_100 output.
CLEAR demo_conn-mark.
MOVE-CORRESPONDING wa_spfli TO demo_conn.
CLEAR wa_spfli.
ENDMODULE.
MODULE user_command_0100 input.
IF demo_conn-mark = 'X'.
LEAVE PROGRAM.
ENDIF.
MOVE-CORRESPONDING demo_conn TO wa_spfli.
SELECT SINGLE
cityfrom airpfrom cityto airpto fltime deptime arrtime
INTO CORRESPONDING FIELDS OF wa_spfli
FROM spfli
WHERE carrid = wa_spfli-carrid AND connid = wa_spfli-connid.
ENDMODULE.
The static next dynpro number of dynpro 100 is 100. It uses components of the structure DEMO_CONN, applied from ABAP Dictionary, and looks like this:
The structure DEMO_CONN was specially created in ABAP Dictionary for dynpros that use the flight data model. In addition to the components of the database table SPFLI, it also contains the component MARK. MARK uses the domain S_FLAG, which can only have the fixed values space and X. On the dynpro above, the ABAP Dictionary text for MARK is overwritten with 'Cancel'. For all other fields, the ABAP Dictionary texts are retained. The input attribute of some fields was deactivated in Screen Painter.
Users can enter values for the airline and flight number. Automatic field checks against check tables in ABAP Dictionary, field helps, and input helps are provided. The field checks are performed automatically before any of the dialog modules in the ABAP program are called. Users cannot enter values for airlines that do not exist in check table SCARR. They also cannot enter values for the flight number that are not in SPFLI or any values for MARK other than space and X. There is no need to program any of these checks in the ABAP program.
The screen flow logic is as follows:
PROCESS BEFORE output.
MODULE init_screen_100.
PROCESS AFTER input.
MODULE user_command_0100.
The module user_command_0100 in the ABAP program reads data from the database table for the key fields specified (and checked) and sends them back to the dynpro at init_screen_100 time. The work area demo_conn, declared using the statement TABLES is used as an interface, while the actual data from the database is edited in the work area wa_spfli. If the user fills the field 'Cancel' with 'X', the program ends.