ARTICLE
Dynpro Fields
The dynpro flow logic does not
contain any data declarations. With the exception of the
OK field that is generated when the
dynpro itself is created, all other data
objects of a dynpro (dynpro fields) created when the screen elements are
defined in Layout Editor are assigned to the latter. The technical
attributes length and data type of a dynpro field are determined by the
element attributes defLg and Format . The
data types of dynpro fields are determined either by reference to
predefined data types from ABAP
Dictionary (except CLNT and FLTP ) or by reference to
global fields of the ABAP program. In Layout Editor, fields can be taken
from 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.
After PBO and before the
screen is sent, there is a data transport of
global data objects for the respective ABAP program to dynpro fields of
the same name. After a user action on the screen, and before or during
PAI editing, the data transport takes place in
the reverse order.
At PBO time, all dynpro fields are transported at the end of
PBO processing, with the exception of 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 the time of PAI,
first the content of all dynpro fields that do not belong to any
table control or step loop and are not
listed in any FIELD statement are transported
into the fields with the same name in the ABAP program. The contents of
the fields of a table control or step loop are transported to the ABAP
program row by row or group by group at the beginning of the respective
loop run. The fields that are listed 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 attribute
Name ). Pure display elements such as text fields or frames are
not associated with dynpro fields and do not necessarily need a unique
name. When input and output fields are created using fields from ABAP
Dictionary, field labels are usually also created 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 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 .
Notes
When dynpro fields are defined with reference to
flat structures in ABAP Dictionary,
the global data objects with the same name of the ABAP program must be
declared with the statement TABLES as
interface work area . Otherwise,
there will be no data transport.
The attributes of dynpro fields that have not been created by copying
from the program or ABAP Dictionary must be set in Screen Painter. In
particular, the name of the OK field
must be determined for every dynpro, so that the dynpro field will
actually be analyzed by the runtime environment.
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 also the modifying effect of special
characters, the attribute Without Template can be activated in
Screen Painter . However, the template cannot be deactivated for
selection screens .
If the type of the dynpro field is a numeric type defined in ABAP
Dictionary, the property sign must be set for the type property,
so that negative numbers can be displayed on the screen. This setting is
only possible for domains and not for the
direct specification of a predefined type for
data elements or structure components.
If a negative number is enters in an input field, although the property
is not set, the number is returned with an error message. If the
associated ABAP data object when the dynpro is called contains a
negative number, a non-handleable exception is raised.
On the screen, the content of dynpro fields is displayed as
character-like. This means that the displayed value may differ from the
internal representation. This applies in particular for the display of
initial values. On the screen, all initial fields apart from those of
type STRING or SSTRING are filled with blank characters,
while internally they contain a type-specific initial value. Initial
fields of type STRING and SSTRING are empty on the screen,
which means that the cursor cannot be moved within the output length.
To enable explicit data transports between an ABAP program and dynpro
fields, function modules such as DYNP_UPDATE_FIELDS are used.
ABAP fields of types string or xstring can be bound to
dynpro fields of the same name, just like fields of fixed length.
However, note that there are no dynpro fields of variable length. The
length of a dynpro field is always defined in Screen Painter by the
element attribute defLg . In data transports between
strings in the ABAP program and dynpro fields of the same names, dynpro
fields behave like target or source fields of fixed length, independent
of their data type, and the respective
conversion rules apply, especially the following:
If, during the transport of a character string or byte string to a
dynpro field, the string contains more characters than the length of the
dynpro field, any surplus characters or bytes are cut off. Since a
dynpro field may not exceed 132 characters of length, only up to 132
characters or bytes of a character string or byte string may be
transported to the dynpro.
When transporting a character-like dynpro field to the ABAP program,
trailing blanks are ignored.
These restrictions apply to the transport to and from normal
input/output fields as well as to fields in table controls without an a
ssigned internal table and to the use of dropdown boxes .
For special handling of decimal floating point
numbers , refer to Decimal
Floating Point Numbers .
For special handling of fields of the type CURR , refer to
Currency Fields .
For special handling of fields of the type QUAN , refer to
Quantity Fields .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved