Get Example source ABAP code based on a different SAP table
ABAP_DYNPRO - Dynpro Fields The dynpro flow logic does not contain any data declarations. Apart from the OK field that is created when the dynpro itself is created, all other data objects of a dynpro (dynpro fields) are created when the screen elements are defined in the Layout Editor and assigned to the latter. The technical properties length and data type of a dynpro field are determined by the element properties <(>defLg<)> and <(>Format<)>. The data types of dynpro fields are determined either by reference to built-in data types from the ABAP Dictionary (except CLNT and FLTP ) or by reference to global fields of the ABAP program. In the Layout Editor, fields can be copied from the ABAP Dictionary or the ABAP program, in which case name, length and data type of the dynpro fields are automatically defined in a matching way. All elementary data types except enumerated types are possible. After PBO processing and before the screen layout is sent, there is a data transport of global data objects for the respective ABAP program to identically named dynpro fields. After a user action on the screen and before or during PAI processing, the data transport takes place in reverse order. At PBO time, all dynpro fields are transported at the end of PBO processing, except for fields that are defined in table controls or in step loops. The latter are processed in loops in the flow logic and transported from the ABAP program to the dynpro after each loop execution. At PAI time, first the content of all dynpro fields that do not belong to any table control or step loop and are not specified in any FIELD statement is transported into the identically named fields in the ABAP program. The content of the fields of a table control or step loop is transported to the ABAP program line by line or group by group at the beginning of the respective loop run. The fields that are specified in the FIELD statements of the dynpro flow logic are transported upon execution of the corresponding FIELD statement. Input and output fields must have a unique name (element property <(>Name<)>). Pure display elements such as text fields or frames are not linked with dynpro fields and do not necessarily need a unique name. When input and output fields are created by using fields from the ABAP Dictionary, the system usually also creates field labels using texts from the dictionary. The default name for these text fields is the same name as the dynpro fields of the input and output fields. Apart from the dynpro fields defined in the Screen Painter, a dynpro also knows the system fields of the ABAP program. In contrast to the program, these system fields are exclusively addressed as syst-name.
Latest notes:
When dynpro fields are defined with reference to flat structures in the ABAP Dictionary, the identically named global data objects of the ABAP program must have been declared with the statement TABLES as an interface work area. Otherwise, there will be no data transport.
The properties of dynpro fields that were not created by copying from the program or ABAP Dictionary must be set in the Screen Painter. In particular, the name of the OK field must be determined for every dynpro, so that the dynpro field is actually evaluated by the runtime framework.
When dynpro fields with character-like dictionary type are passed, lowercase letters are transformed to uppercase letters by default. This behavior can be overridden in the Screen Painter. Furthermore, the preservation of lowercase letters can be defined for data elements in the semantic properties of a domain.
When dynpro fields are received from input fields on the screen, input fields are templates that expect a certain format depending on the data type of the underlying dynpro field. When passed to the dynpro field, the input is converted to a value of the appropriate type. This also means that some characters function as special characters by default.
The ! character in the initial position of an input field on the screen deletes all characters in the field before the data transport.
The = character in the initial position of an input field on the screen initiates a search using search helps .
If an input field contains only blanks and _ characters, the latter are transported as blanks. To deactivate the template and therefore the modifying effect of special characters, the property Without Template can be activated in the Screen Painter. However, the template cannot be deactivated for selection screens.
