Skip to end of metadata
Go to start of metadata

MODULE POOL PROGRAMMING
Screens
Screens are the most general type of user dialog that you can use in ABAP programs. You do
not define them in ABAP programs, but instead in the Screen Painter. A screen consists of the
input/output mask and the flow logic. You can define screens for any program with type 1, M, or
F.
The screens in a single ABAP program can be combined to form screen sequences [Page 1000].
You can call single screens or screen sequences either using a transaction code from outside the
ABAP program, or by using the CALL SCREEN statement in the corresponding ABAP program.
When you call a screen or screen sequence, the screen flow logic takes control of the ABAP
program execution [Page 937]. You can define screen sequences dynamically by setting the next
screen attribute for a screen dynamically in the ABAP program.
A screen consists of the input/output mask and the flow logic. The screen flow logic is divided
into the Process Before Output (PBO) event, which is processed before the screen is displayed,
and the Process After Input (PAI) event, which is processed after a user action on the screen.
The following diagram shows the place of screens between the GUI status and the ABAP
program:
ABAP program
Declaration
part for global data
PBO MoPdBuleOModules
PAI Modules
Screen
PBO Screen PAI
GUI status
The screen flow logic calls dialog modules in the ABAP program, either to prepare the screen for
display (PBO event) or to process the user's entries (PAI event). Screens are dynamic programs,
and have their own data objects, called screen fields. These are linked to the input/output fields
that appear on the screen itself. When the screen is displayed, and when it finishes processing,
the system passes data between the screen fields and data objects in the ABAP program. Data
is copied between identically-named fields.
Each screen has a GUI status, containing a menu bar, standard toolbar, and an application
toolbar. Like screens, GUI statuses are independent components of the ABAP program. You
create them in the ABAP Workbench using the Menu Painter. You assign GUI statuses to
screens dynamically in your ABAP programs. Each screen is linked to the current GUI status by
a special screen field into which the corresponding function code is placed whenever the user
chooses a function. The screen passes the function code to the ABAP program just like any
other screen field. You can then read it in the program.
Screen Elements
You create screens using the Screen Painter [Ext.] in the ABAP Workbench [Ext.]. The relevant
documentation provides comprehensive information about creating screens and their elements.
The following sections contain information about screen elements that is important from the
aspect of ABAP programming using screens.
Screen Attributes
Like all objects in the R/3 Repository, screens have attributes that both describe them and
determine how they behave at runtime. Important screen attributes for ABAP programming:
_ Program
The name of the ABAP program (type 1, M, or F) to which the screen belongs.
_ Screen number
A four-digit number, unique within the ABAP program, that identifies the screen within the
program. If your program contains selection screens [Page 681], remember that
selection screens and Screen Painter screens use the same namespace. For example, if
you have a program with a standard selection screen, you may not contain any further
screens with the number 1000. Lists, on the other hand, have their own namespace.
_ Screen type
A normal screen occupies a whole GUI window. Modal dialog boxes only cover a part of
a GUI window. Their interface elements are also arranged differently. Selection screens
are generated automatically from the definition in the ABAP program. You may not define
them using the Screen Painter. A subscreen is a screen that you can display in a
subscreen area on a different screen in the same ABAP program.
_ Next screen
Statically-defined screen number, specifying the next screen in the sequence. If you
enter zero or leave the field blank, you define the current screen as the last in the chain.
If the next screen is the same as the current screen, the screen will keep on calling itself.
You can override the statically-defined next screen in the ABAP program.
_ Cursor position
Static definition of the screen element on which the cursor is positioned when the screen
is displayed. By default, the cursor appears on the first input field. You can overwrite the
static cursor position dynamically in your ABAP program.
 _ Screen group
Four-character ID, placed in the system field SY-DYNGR while the screen is being
processed. This allows you to assign several screens to a common screen group. You
can use this, for example, to modify all of the screens in the group in a uniform way.
Screen groups are stored in table TFAWT.
 _ Hold data
If the user calls the screen more than once during a terminal session, he or she can
retain changed data as default values by choosing System _ User profile _ Hold data.
_ OK_CODE field
Every screen has a twenty-character OK_CODE field (also known as the function code
field), which is not displayed on the screen. User actions that trigger the PAI event also
place the corresponding function code into this field, from where it is passed to the ABAP
program. You can also use the command field in the standard toolbar to enter the
function code. You must assign a name to the OK_CODE field to be able to use it for a
particular screen.
All screen elements have a set of attributes, some of which are set automatically, others of which
have to be specified in the Screen Painter. They determine things such as the layout of the
screen elements on the screen. You can set the attributes of screen elements in the Screen
Painter - either for a single element, or using the element list, which lists all of the elements
belonging to the current screen. Some of the attributes that you set statically in the Screen
Painter can be overwritten dynamically in the ABAP program. For a detailed list of all screen
element attributes, refer to Working with Element Attributes [Ext.] in the Screen Painter
documentation.
BC - ABAP Programming SAP AG  Screen Fields   530 April 2001
Screen Fields
Screen fields are fields in the working memory of a screen. Their contents are passed to
identically-named fields in the ABAP program in the PAI event, and filled from the same
identically-named fields in the program in the PBO event. The screen fields are linked with the
input/output fields on the screen and with the OK_CODE field. Input and output fields must have
a unique name (element attribute Name). This assigns them to a screen field with the same
name, which allows you to work with their values in an ABAP program.
The technical attributes length and data type of a screen field are defined by the element
attributes DefLg and Format. For the data type, you can select [Ext.] one of the data types in the
ABAP Dictionary [Page 105]. These are converted appropriately when data is passed between
the screen and the ABAP program. When you use fields [Ext.] from the ABAP Dictionary or the
ABAP program, the name, length, and data type of the screen fields are defined automatically.
Otherwise, you must set these attributes in the Screen Painter. Most importantly, you must
specify the name of the OK_CODE field for each screen, so that a corresponding screen field
can be defined. This allows you to use the OK_CODE field in your ABAP programs.
Display elements such as text fields or boxes are not linked to screen fields, and do not need a
unique field name. When you create input and output fields by using [Ext.] ABAP Dictionary
fields, the system usually also creates field labels using texts from the ABAP Dictionary. The
default name for these text fields is the same name as the screen fields of the input and output
fields.
As well as the screen fields defined in the Screen Painter, screens also recognize the same
predefined system fields [Page 132] as the ABAP program. However, in screens, system fields
are administered in the structure SYST, not SY. Therefore, you must address them using the
form SYST-<name>.
Suppose we have the following program extract:
DATA: TEXT(10),
NUMBER TYPE I.
CALL SCREEN 100.
Screen 100, created in the Screen Painter, contains two fields SPFLI-CARRID and
SPFLI-CONNID from the ABAP Dictionary, and two fields, TEXT and NUMBER, from
the ABAP program. It also contains three text fields and a box. Overall, the screen
looks like this:
 
Screen fields
Airline
Flight number
ABAP field 1
ABAP field 2
Group box
The columns in the element list that are relevant for the screen fields are the
following:
Name Type defLg Format Text or I/O template
Box Frame 62 Group box
%#AUTOTEXT001 Text 14 Screen fields
SPFLI-CARRID Text 16 Airline
SPFLI-CARRID I/O 3 CHAR ___
SPFLI-CONNID Text 15 Flight number
SPFLI-CONNID I/O 4 NUMC ____
%#AUTOTEXT002 Text 10 ABAP field 1
TEXT I/O 10 CHAR __________
%#AUTOTEXT003 Text 10 ABAP field 2
NUMBER I/O 11 INT4 ___________
OK 20 OK ________________
The screen has four input/output fields. Each of these fields is linked to an
identically-named screen field. The data types and lengths of the screen fields are
copied from the ABAP Dictionary or the ABAP program. In our example, the
OK_CODE field still needs a name - for example, OK_CODE - to assign it to a
screen field.
You can either assign a name to display fields with the type frame and text, or the
system can automatically create field names for them. The texts that come from the
ABAP Dictionary have the same names as the input/output fields. The texts created
in the Screen Painter have generated names.
The last column shows the contents of the screen elements on the screen.
Input/output fields only contain the template for the field, since the contents will not
be known until runtime. The contents of the output fields, on the other hand, are
statically-defined in the Screen Painter and cannot be affected by screen fields.
 
Screen Flow Logic
Screen flow logic contains the procedural part of a screen. You create it in the flow logic editor
[Ext.], which is very similar to the ABAP Editor. The language used to program screen flow logic
has a similar syntax to ABAP, but is not part of ABAP itself. It is sometimes referred to as screen
language.
Unlike ABAP programs, screen flow logic contains no explicit data declarations. You define
screen fields by placing elements on the screen mask.
The screen flow logic is like an ABAP program in that it serves as a container for processing
blocks. There are four event blocks, each of which is introduced with the screen keyword
PROCESS:
PROCESS BEFORE OUTPUT.
...
PROCESS AFTER INPUT.
...
PROCESS ON HELP-REQUEST.
...
PROCESS ON VALUE-REQUEST.
...
As in ABAP, the event block is introduced by the corresponding keyword statement, and it
concludes either when the next block is introduced, or at the end of the program. The first two
statements are created automatically by the Screen Painter when you create a new screen. The
corresponding events are triggered by the runtime environment:
_ PROCESS BEFORE OUTPUT (PBO) is automatically triggered after the PAI processing
of the previous screen and before the current screen is displayed. You can program the
PBO processing of the screen in this block. At the end of the PBO processing, the
screen is displayed.
_ PROCESS AFTER INPUT (PAI) is triggered when the user chooses a function on the
screen. You can program the PAI processing of the screen in this block. At the end of
the PAI processing, the system either calls the next screen or carries on processing at
the point from which the screen was called.
_ PROCESS ON HELP-REQUEST (POH) and PROCESS ON VALUE-REQUEST (POV)
are triggered when the user requests field help (F1) or possible values help (F4)
respectively. You can program the appropriate coding in the corresponding event blocks.
At the end of processing, the system carries on processing the current screen.
As is normal with events, you must only program event blocks for the events to which you want
the flow logic to react. However, the screen flow logic must contain at least the two statements
PROCESS BEFORE OUTPUT and PROCESS AFTER INPUT in the correct order.
Within the event blocks, you can use the following keywords:
Keyword Function
MODULE Calls a dialog module in an ABAP program
FIELD Specifies the point at which the contents of a screen field should be transported
ON Used in conjunction with FIELD
VALUES Used in conjunction with FIELD
CHAIN Starts a processing chain
ENDCHAIN Ends a processing chain
CALL Calls a subscreen
LOOP Starts processing a screen table
ENDLOOP Stops processing a screen table
The functions of the individual statements are described in the following sections.
 
Processing Screens
There are two ways of calling a screen. You can either use a transaction code, or the CALL
SCREEN statement in an ABAP program. When you call a screen, the PROCESS BEFORE
OUTPUT event (PBO) is called, and the corresponding event block in the screen flow logic is
processed. The screen itself is then displayed until the user triggers the PROCESS AFTER
INPUT (PAI) event by choosing a function. In between, there may be field or input help
processing. The corresponding event blocks in the flow logic are processed, if they exist. The
main purpose of event blocks in the screen flow logic is to call dialog modules in the ABAP
program and to provide the ABAP program with data.
 
User Actions on Screens
There are various ways in which users can interact with screens.
Filling Input Fields
Users can enter values in any input field on the screen, or change the value using the mouse, in
the case of radio buttons and checkboxes. The contents are placed in the corresponding screen
field. Filling an input field does not normally trigger the PAI event. Exceptions to this are
Checkboxes and Radio Buttons with Function Codes  and input fields with Drop Down
Boxes  
Triggering the PAI Event
There is a series of user actions that conclude the user's interaction with the screen in the
SAPgui and pass control back to the runtime environment on the application server, where the
PAI event is triggered.
These are:
_ Choosing a pushbutton on the screen
_ Selecting a checkbox or radio button to which a function code is assigned.
_ Choosing a function in the menu, standard toolbar, or application toolbar.
_ Choosing a function key on the keyboard.
_ Selecting an entry from a drop down box.
All of these actions have in common that they are linked to a function code.
 _ The function code of a pushbutton, checkbox, radio button, or dropdown box on the screen is
set in the corresponding element attributes.
 _ The function codes in menus, the standard toolbar, and the application toolbar are set in the
GUI status.
_
    The function codes of function keys are also assigned in the GUI status.
If the OK_CODE field in the element list has a name (and is therefore assigned to the
corresponding screen field), it is filled with the corresponding function code when the user
chooses the function. If there is a field in the ABAP program with the same name, you can find
out the function that the user chose by querying its contents in a PAI module. If the OK_CODE
field does not have a name, the PAI event is still triggered, but there is no screen field into which
the function code can be passed. Note also that the OK_CODE field is filled with the contents of
the identically-named field in the ABAP program in the PBO event.
The PAI event is always triggered when the user resizes a screen containing elements for which
the Resizing attribute is active. This applies to table controls, subscreens, and custom controls.
Processing Input/Output Fields
Input/output fields can be 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 linking them to a screen field. The data type of the
screen field determines the input format. For example, you cannot enter letters in a numeric field.
The screen recognizes when you try to enter invalid values. Radio buttons and checkboxes
always have the data type CHAR and length 1.
 A selected radio button or checkbox has the
value 'X', when empty, both have the value SPACE.
The ABAP program must contain identically-named data objects that correspond to the screen
fields, otherwise data may be lost. The ABAP data types that correspond to the screen data
types are listed in a table in the Data Types in the ABAP Dictionary  .
 
The ABAP fields for checkboxes and radio buttons must have type C and length 1.
After the PBO event has been processed, the screen fields are filled with the values from the
ABAP fields. Before or during the PAI event, the values from the screen fields are written to the
ABAP fields. Note that only one radio button within a group can be selected. If more than one of
the fields contains the value 'X', the program terminates.
To ensure that screen fields and ABAP fields always correspond exactly, use the following
procedure.
Local Program Fields
If you want to use input/output fields in one program only, you should create them in the ABAP
program, activate the program, and then copy [Ext.] the fields from the ABAP program to the
screen. Afterwards, however, you must avoid changing the fields in the ABAP program.
Screen Fields with Dictionary Reference
If your input/output fields are required in more than one program, and you want to use
information from the ABAP Dictionary, such as field labels, field help, and input help, you should
copy [Ext.] fields from the ABAP Dictionary. You can refer to both structures and database
tables.
You must then declare identically-named fields as an interface work area in the ABAP program
using the TABLES statement. Declaring an identically-named field using a TYPES reference to
the data type in the ABAP Dictionary is insufficient for data to be transferred between the screen
and the ABAP program.
To avoid naming conflicts between screen fields, work areas in programs, and database tables, it
is often worth defining your own ABAP Dictionary structure for screens, containing all of the
input/output fields you want to use for one or more screens of a program, or even for a whole
development class. The work areas that you declare with TABLES in the ABAP program then
function exclusively as an interface between the program and the screen. If necessary, you can
assign values between program fields and the interface work area.
The advantage of referring to ABAP Dictionary data types is that both the screen fields and the
fields in the ABAP program are updated automatically if the data type changes.
Local program fields
 

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_input_output.
DATA: input TYPE i,
output TYPE i,
radio1, radio2, radio3, box1, box2, box3, exit.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  CLEAR input.
  radio1 = 'X'.
  CLEAR: radio2, radio3.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  output = input.
  box1 = radio1.
  box2 = radio2.
  box3 = radio3.
  IF exit NE space.
    LEAVE PROGRAM.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_0100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Radio button 1 Checkbox 1
Radio button 2 Checkbox 2
Radio button 3 Checkbox 3
Cancel
0
The part of the element list relevant for the screen 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
ENDMODULE.
The statically-defined next screen for screen 100 is 100. It uses components of the
structure SDYN_CONN, copied [Ext.] from the ABAP Dictionary, and looks like this:
Cancel
Airline
Flight number
From airport
From
To airport
To
Departure time
Duration 0:00
00:00:00
Arrival time 00:00:00
The structure SDYN_CONN exists in the ABAP Dictionary specially for screens that
use the flight data model. It contains the components of the database table SPFLI,
but also a component MARK. MARK uses the domain S_FLAG, which may only
have the values SPACE and X. On the above screen, the ABAP Dictionary text for
MARK has been overwritten with 'Cancel'. For all other fields, the ABAP Dictionary
texts have been retained. The input attribute of some of the fields has been switched
off in the Screen Painter.
Users can enter values for the airline and flight number. Automatic field checks
against check tables in the ABAP Dictionary, field help, and input help are
automatically available. The field checks are performed automatically before any of
the dialog modules in the ABAP program are called. Users cannot enter values for
the airline that do not exist in the check table SCARR, values for the flight number
that are not in SPFLI, or 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_100 in the ABAP program reads data from the
database table with the key fields specified (and checked) on the screen, and sends
them back to the screen in the PBO module INIT_SCREEN_100. The work area
SDYN_CONN, defined using the TABLES statement, serves as an interface between
the program and the screen. Meanwhile the data from the database is processed in
the work area WA_SPFLI. If the user selects the screen field 'Cancel' (value 'X'), the
program ends.
Pushbuttons on the Screen
Pushbuttons are the only elements of screens that trigger the PAI event when the user chooses
them. In the attributes of a pushbutton, you can specify a function code up to 20 characters long.
Pushbuttons have a label - the text that you specify statically in the attributes - and can also have
icons. If you set the Output field attribute for a pushbutton, you can also set its text dynamically in
the ABAP program. To do this, you must create a field in the ABAP program with the same
name as the pushbutton. You must then assign the required text to the field before the screen is
displayed. You can also assign icons to dynamic texts on pushbuttons by including the icon code
in the text. The icon codes are all contained in the include program <ICON>. For example, the
ICON_CANCEL ( ) icon has the code  (0W).
In each PAI event, the function code, as long as it is not empty, is placed in the system field
SYST-UCOMM (SY-UCOMM) and assigned to the OK_CODE field. Empty function codes are
placed in neither the SY-UCOMM field nor the OK_CODE field. The function code of a
pushbutton is empty if you have not entered it in the corresponding attribute in the Screen
Painter. Before you can work with the OK_CODE field, you must assign a name to it in the
Screen Painter. For further information, refer to Reading Function Codes [Page 555].
The main way of allowing users to choose functions that trigger the PAI event and send function
codes to the program is through the GUI status. The main reason is one of space - the GUI
status can contain many more functions than you would be able to place on the screen as
pushbuttons.
However, you should use pushbuttons in the following cases:
 _ Very important and frequently-used function codes that should appear on the screen as
well as in the GUI status, for example, the Execute, Display, and Change functions on
the initial screen of the ABAP Editor.
 _ Applications that only use pushbuttons, where function codes in the GUI status make no
sense - for example, in a calculator application. The function codes of the corresponding
pushbuttons have no corresponding function in the GUI status elements, and only exist
as attributes of screen elements.
 _ When you have a GUI status that is used for a large number of screens, but use it on
screens that have a particular function that is not required anywhere else. In this case,
you should place it on the screen as a pushbutton.
When you define pushbuttons, you must ensure that your function code is either the same as a
corresponding function in the GUI status, or does not accidentally coincide with the function code
of an entirely different function. Although the consistency of function codes in GUI statuses is
checked in the Menu Painter, this is not possible for pushbuttons, since the GUI status of a
screen is not known until runtime.
Pushbuttons on screens.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_push_button.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code,
output(8) TYPE c.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'BUTTON_EXIT'.
      LEAVE PROGRAM.
    WHEN 'BUTTON_1'.
      output = 'Button 1'(001).
    WHEN 'BUTTON_2'.
      output = 'Button 2'(002).
    WHEN 'BUTTON_3'.
      output = 'Button 3'(003).
    WHEN 'BUTTON_4'.
      output = 'Button 4'(004).
    WHEN OTHERS.
      output = save_ok.
  ENDCASE.
ENDMODULE.                    "USER_COMMAND_0100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Cancel
Pushbutton 1 Pushbutton 2
Pushbutton 3 Pushbutton 4
The part of the element list relevant for the screen fields is as follows:
Name Type Format Text Function code
OUTPUT I/O CHAR
BUTTON1 Push Pushbutton 1 BUTTON_1
BUTTON2 Push Pushbutton 2 BUTTON_2
BUTTON3 Push Pushbutton 3 BUTTON_3
BUTTON4 Push Pushbutton 4 BUTTON_4
EXIT_BUTTTON Push Cancel BUTTON_EXIT
OK_CODE OK OK
The input option for the screen field OUTPUT has been switched off in the Screen
Painter.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.
When the user chooses a pushbutton, the PAI event is triggered. The function code
of the pushbutton is assigned to the screen field OK_CODE, which is then passed
onto the ABAP field with the same name. The module USER_COMMAND_0100 is
then processed.
Firstly, the contents of the OK_CODE field are copied to the auxiliary variable
SAVE_OK code, and OK_CODE is initialized. You should always do this, since it
ensures that the screen field OK_CODE has always been initialized before the PBO
event and can therefore not unintentionally contain an incorrect value.
Next, in the CASE structure, a text symbol is assigned to the OUTPUT field
according to the button that the user chose. This is displayed in the output field on
the screen. If the user chooses Cancel, the program ends.
Checkboxes and Radio Buttons with Function Codes
In the Screen Painter, you can assign a function code (up to 20 characters long) to checkboxes
and radio buttons.
Checkboxes and radio buttons without a function code behave like normal input/output fields.
Clicking the object changes the contents of the field, but does not trigger the PAI event. (Clicking
a pushbutton, on the other hand, always triggers the PAI event, even if it has an empty function
code.)
When a function code is assigned to a checkbox or radio button, clicking it not only changes
the field contents, but also triggers the PAI event and places the function code in the OK CODE
field.
While it is possible to assign an individual function code to each checkbox, you can only assign
one function code to all of the radio buttons in a group. When you assign a function code to a
radio button in the Screen Painter, the system automatically applies the same function code to all
of the other radio buttons in the group.
You can use checkboxes and radio buttons with function codes as follows:
 _ For processing parts of screens (context-sensitive processing). For example, only when a
radio button or checkbox is selected is particular data read and placed in the corresponding
input/output fields.
 _ You can fill fields with patterns depending on checkboxes or radio buttons. A typical example
would be formatting settings for letters. The input fields can all be processed separately, but
it is possible to fill all input fields simultaneously and consistently by choosing a pattern.
 _ You can control dynamic screen modifications [Page 611] directly using checkboxes or radio
buttons. For example, you can make sure that an input/output field cannot accept input until
the user selects a radio button.
As when you create pushbuttons [Page 542], you should ensure when you assign function codes
to checkboxes and radio buttons that they do not coincide with function codes from the GUI
status.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_check_radio.
DATA: radio1(1) TYPE c, radio2(1) TYPE c, radio3(1) TYPE c,
field1(10) TYPE c, field2(10) TYPE c, field3(10) TYPE c,
box TYPE c.
DATA: ok_code TYPE sy-ucomm,
save_ok TYPE sy-ucomm.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE user_command_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'RADIO'.
      IF radio1 = 'X'.
        field1 = 'Selected!'.
        CLEAR: field2, field3.
      ELSEIF radio2 = 'X'.
        field2 = 'Selected!'.
        CLEAR: field1, field3.
      ELSEIF radio3 = 'X'.
        field3 = 'Selected!'.
        CLEAR: field1, field2.
      ENDIF.
    WHEN 'CANCEL'.
      LEAVE PROGRAM.
  ENDCASE.
ENDMODULE.                    "user_command_0100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Radio button 1
Radio button 2
Radio button 3
Cancel
The part of the element list relevant for the screen fields is as follows:
Name Type DefLg Format Function code
RADIO1 Radio 1 CHAR RADIO
FIELD1 I/O 10 CHAR
RADIO2 Radio 1 CHAR RADIO
FIELD2 I/O 10 CHAR
RADIO3 Radio 1 CHAR RADIO
FIELD3 I/O 10 CHAR
BOX Check 1 CHAR CANCEL
OK_CODE OK 20 OK
The input option for the screen fields FIELD1 to FIELD3 has been switched off in the
Screen Painter.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE user_command_0100.
Each time you select one of the three radio buttons, the PAI event is triggered and
the function code RADIO and the contents of the screen fields are passed to the
ABAP program. The dialog module USER_COMMAND_100 fills the fields FIELD1 to
FIELD3 according to the radio button that was selected. These field contents appear
the next time the screen is sent.
The PAI event is also triggered if you select the checkbox. In this case, the function
code CANCEL is passed to the ABAP program, and the dialog module
USER_COMMAND_100 terminates the program immediately.
Using GUI Statuses
A GUI status is an independent component of an ABAP program. You create them in the ABAP
Workbench [Ext.] using the Menu Painter [Ext.]. The relevant documentation provides
comprehensive information about creating GUI statuses and their elements. The most important
details are contained below.
GUI Status
The function of a GUI status is to provide the user with a range of functions on a screen. Each
function has an associated function code, and when the user chooses a function, the PAI event is
triggered. In each PAI event, the function code, as long as it is not empty, is placed in the
system field SYST-UCOMM (SY-UCOMM) and assigned to the OK_CODE field. Empty function
codes are placed in neither the SY-UCOMM field nor the OK_CODE field. Before you can work
with the OK_CODE field, you must assign a name to it in the Screen Painter. For further
information, refer to
All function codes in an ABAP program, apart from those only assigned to pushbuttons on
screens, are defined and adminstered in the Menu Painter.
When you define a function code in the Menu Painter, you assign it to a menu entry in a menu
bar, and possibly also to a freely-assigned function key on the keyboard. Function codes that are
assigned to a function key can also be assigned to an icon in the standard toolbar or a
pushbutton in the application toolbar. A GUI status consists of a menu bar, a standard toolbar,
an application toolbar, and a function key setting. For each function code, there is a static or
dynamic function text [Ext.]. Dynamic function texts allow you to use context-sensitive texts in
your ABAP program.
The user interface is a visualization of all possible functions, and is meant to make programs
easier to use. From a technical point of view, you could just enter the function code in the
command field and trigger the PAI event by pressing ENTER. However, a GUI status should
contain all possible function codes as menu entries. The most important functions should also
be assigned to function keys, and the most important of these should also be assigned to icons in
the standard toolbar or the application toolbar.
In the Menu Painter, the functions that you assign to the icons in the standard toolbar must also
be assigned to particular function keys. You cannot assign them freely. Instead, the system
automatically assigns them to the corresponding function key when you assign the function code
to an icon. You should always activate at least one of the Back (F3), Exit (shift+F3), and
Cancel (F12) functions, so that the user can always leave the screen in the normal fashion.
The assignment of function keys to pushbuttons in the application toolbar is not fixed.
Whenever you assign function codes to interface elements, you should refer to the ergonomic
guidelines in the SAP Style Guide [Ext.]. The Menu Painter provides you with help in this respect,
since you can use the Display standards function and corresponding checks.
As well as the function codes for Normal application functions, which trigger the PAI event, you
can also create function codes in the Menu Painter with other functions, for example, to call
another transaction or trigger a system functions. You can also create special function codes for
pushbuttons on screens, but you must assign another function type to the function code in either
the Menu Painter or the Screen Painter.
You can also use the Menu Painter to create area menus. An area menu is a user interface that
does not belong to an ABAP program and may therefore not trigger any PAI events. It may only
contain function codes that call transactions or system functions. Examples of area menus are
the initial screen of the R/3 System (S000) and the initial screen of the ABAP Workbench (S001).
Special Function Keys and Function Codes
Some keys and function codes have special functions. This section deals with the special
functions on screens. There are also special functions that apply to lists.
  Reserved Function Keys
The following function keys do not trigger the PAI event, but are reserved for other functions:
_ F1 calls the field help
_ F4 calls the input help
_ F10 places the cursor in the menu bar
  Function Keys for the Standard Toolbar
The following function keys are firmly assigned to icons in the standard toolbar. The function
code that you assign and the corresponding ABAP coding should reflect the sense of the icon.
The EXCLUDING function allows you to change the appearance and function of a GUI status
dynamically. This is useful if the individual user interfaces for a range of screens are very similar.
You can define a single global status, and then just deactivate the functions you do not need
using EXCLUDING. Specify <f> to deactivate the function code stored in field <f>. Specify <itab>
to deactivate all function codes stored in the internal table <itab>. Field <f> and the lines of table
<itab> should be of type C, and have length 20.
You should set the GUI status for a screen in the PBO event. If you do not specify a GUI status
for a screen, it is displayed with the interface of the previous screen. If you do not specify a GUI
status for the first screen of a program, it has no user interface, and the user may not be able to
leave the screen.
Setting a GUI Title
As well as the GUI status, a user interface also contains a GUI title, which you also create using
the Menu Painter. To assign a GUI status to a screen, use the ABAP statement
SET TITLEBAR <title> [OF PROGRAM <prog>]  [WITH <g1 >... <g9>].
This statement defines the title of the user interface for all subsequent screens of a screen
sequence until another is set using a new SET TITLEBAR statement. The GUI title <title> must
be a component of the current ABAP program, unless you use the OF PROGRAM addition in the
SET TITLEBAR statement to set a GUI status of another program <prog>.
A GUI title can contain up to nine placeholders &1 ... &9 that can be replaced with the contents of
the corresponding fields <g1> ... <g9> in the WITH addition. The system also replaces '&'
placeholders in succession by the contents of the corresponding <gi> parameters. To display an
ampersand character '&', repeat it in the title '&&'.
You should set the GUI title for a screen in the PBO event.
GUI status and screen

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_gui_status.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code,
output LIKE ok_code.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  SET TITLEBAR '100'.
ENDMODULE.                    "INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'BACK' OR 'EXIT' OR 'CANCEL'.
      LEAVE PROGRAM.
    WHEN OTHERS.
      output = save_ok.
  ENDCASE.
ENDMODULE.                    "USER_COMMAND_0100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
The part of the element list relevant for the screen fields is as follows:
Name Type Format
OUTPUT I/O CHAR
OK_CODE OK OK
The input option for the screen field OUTPUT has been switched off in the Screen
Painter.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_0100.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.
The PBO module INIT_SCREEN_100 sets the GUI status STATUS_100 and a title
100. The GUI status was created using the Menu Painter as follows:
Menu bar
Menu Demo:
Function code Text
SAVE Save
PRINT Print
DELETE Delete
EXIT Exit
Menu Edit:
Function code Text
MARK Select
SELE Choose
SEARCH Find
SEARCH+ Find next
TOP First page
PAGE_UP Previous page
PAGE_DOWN Next page
BOTTOM Last page
CANCEL Cancel
Menu Goto:
Function code Text
BACK Back
Menu Extras:
Function code Text
FUNCT_F5 Function 1
FUNCT_F6 Function 2
FUNCT_F7 Function 3
FUNCT_F8 Function 4
Menu Environment:
Function code Text
MENU_1 Menu 1
MENU_2 Menu 2
MENU_3 Menu 3
Standard toolbar
Icon Function code Text
SAVE Save
BACK Back
EXIT Exit
CANCEL Cancel
PRINT Print
SEARCH Find
SEARCH+ Find next
PAGE_UP Previous page
PAGE_DOWN Next page
BOTTOM Last page
CANCEL Cancel
1 SELE
2 MARK
3 DELETE
4 FUNCT_F5 Function 1
5 FUNCT_F6 Function 2
function keys
Key Function code Text Icon
F2 SELE Choose
F9 MARK Select
Shift+F2 DELETE Delete
F5 FUNCT_F5 Function 1
F6 FUNCT_F6 Function 2
F7 FUNCT_F7 Function 3
F8 FUNCT_F8 Function 4
All function codes exist as menu entries, but not all of them are assigned to function
keys. The function codes in the standard toolbar activate the icons and are
automatically assigned to their function keys. Some of the additional function keys
are assigned to the application toolbar.
In the module USER_COMMAND_100, the contents of the OK_CODE field are
copied to the auxiliary variable SAVE_OK code, and OK_CODE is initialized. You
should always do this, since it ensures that the screen field OK_CODE has always
been initialized before the PBO event and can therefore not unintentionally contain
an incorrect value. The function code of the function chosen by the user is then
assigned to the OUTPUT field and displayed in the corresponding screen field (but
not if the user chose BACK, EXIT, or CANCEL, in which cases, the program ends).
The function code SELE can be passed to the ABAP program in the following ways:
_ When you choose Choose in the Edit menu
_ When you choose the pushbutton in the application toolbar
_ When you choose the F2 key on the keyboard
_ When you click the right-hand mouse button and then choose Choose.
_ When you double-click the screen field OUTPUT
_ When you enter SELE in the command field and press ENTER.
The other function codes are passed according to their definition, but without the
double-click function.
Reading Function Codes
In each PAI event that a user triggers by choosing either a pushbutton on the screen or an
element in a GUI status, the corresponding function code is placed into the system field SYSTUCOMM or SY-UCOMM and placed in the OK_CODE field (as long as the function code is not empty). Empty function codes are placed in neither the SY-UCOMM field nor the OK_CODE
field.
In your ABAP programs, you should work with the OK_CODE field instead of SY-UCOMM. There
are two reasons for this: Firstly, the ABAP program has full control over fields declared within it,
and secondly, you should never change the value of an ABAP system field. However, you should
also always initialize the OK_CODE field in an ABAP program for the following reason:
In the same way that the OK_CODE field in the ABAP program and the system field SY-UCOMM
receive the contents of the corresponding screen fields in the PAI event, their contents are also
assigned to the OK_CODE screen field and system field SYST-UCOMM in the PBO event.
Therefore, you must clear the OK_CODE field in the ABAP program to ensure that the function
code of a screen is not already filled in the PBO event with an unwanted value. This is
particularly important when the next PAI event can be triggered with an empty function code (for
example, using ENTER). Empty function codes do not affect SY-UCOMM or the OK_CODE field,
and consequently, the old field contents are transported.
In your application programs, the first step in PAI processing should be to save the function code
in an auxiliary variable and then initialize the OK_CODE field. You can then read the function
code from the auxiliary variable (for example, using a CASE structure), and control the program
flow from there.
The OK_CODE field can have a different name on each screen. However, common practice is to
use the same name for the field on each screen of an ABAP program. You then only need one
field in the ABAP program, with the same name, into which the function code is placed, and from
which you can read it.
Global data declarations:
DATA: OK_CODE LIKE SY-UCOMM,
SAVE_OK LIKE SY-UCOMM.
Your ABAP program must contain a field with the same name as the OK_CODE field
on the screen. To specify the type, you should refer to the system field SY-UCOMM,
since this always corresponds to the type of the OK_CODE field on the screen. At
the same time, you should declare an appropriate auxiliary variable.
PAI module:
MODULE USER_COMMAND_100 INPUT.
SAVE_OK = OK_CODE.
CLEAR OK_CODE.
CASE SAVE_OK.
WHEN...
...
ENDCASE.
ENDMODULE.
In the first PAI module, you should assign the contents of the OK_FIELD to the
auxiliary variable and then clear the OK_CODE field and carry on working with the
auxiliary variable.
 
Finding Out the Cursor Position
After user interaction with the screen, you may need to know the position of the cursor when the
action occurred. This is particularly important if the user chooses the Choose function (F2 or
mouse double-click).
To find out the cursor position, use the following statement:
GET CURSOR FIELD <f> [OFFSET <off>]
[LINE <lin>]
[VALUE <val>]
[LENGTH <len>].
This statement transfers the name of the screen element on which the cursor is positioned during
a user action into the variable <f>. If the cursor is on a field, the system sets SY-SUBRC to 0,
otherwise to 4.
The additions to the GET CURSOR statement have the following functions:
_ OFFSET writes the cursor position within the screen element to the variable <off>.
_ LINE writes the line number of the table to the variable <lin> if the cursor is positioned in
a table control [Page 669]. If the cursor is not in a table control, <lin> is set to zero.
_ VALUE writes the contents of the screen field in display format, that is, with all of its
formatting characters, as a string to the variable <val>.
_ LENGTH writes the display length of the screen field to the variable <len>.
Cursor position on the screen.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_get_cursor.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code.
DATA: input_output(20) TYPE c,
fld(20) TYPE c,
off TYPE i,
val(20) TYPE c,
len TYPE i.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'CANCEL'.
      LEAVE PROGRAM.
    WHEN 'SELE'.
      GET CURSOR FIELD fld OFFSET off VALUE val LENGTH len.
  ENDCASE.
ENDMODULE.                    "USER_COMMAND_0100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Input
Offset
Name
Length
Contents
0
0
The relevant extract of the element list is as follows:
Name Type Format Text Function code
TEXT1 Text Input
INPUT_OUTPUT I/O CHAR
TEXT2 Text Name
FLD I/O CHAR
TEXT3 Text Offset
OFF I/O INT4
TEXT4 Text Contents
VAL I/O CHAR
TEXT5 Text Length
LEN I/O INT4
EXIT_BUTTTON Push Cancel CANCEL
OK_CODE OK OK
The input attribute of all of the input/output fields except INPUT_OUTPUT is inactive.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_0100.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.
The module INIT_SCREEN_100 sets the GUI status STATUS_100 during the PBO
event. In the status, the cancel icon (F12) is active with the function code
CANCEL, and the function key F2 is active with the function code SELE.
When you run the program, the user can select any screen element by doubleclicking
it, or use any screen element connected to the function code SELE. The
output fields on the screen return the cursor position.
Calling ABAP Dialog Modules
The main task of the screen flow logic [Page 532] is to call dialog modules in an ABAP program.
You can do this using the MODULE statement, which can be programmed in the four possible
event blocks of screen flow logic. In the PBO event, you can use this statement to call any dialog
module in the ABAP program that has been defined using
MODULE <mod> OUTPUT.
...
ENDMODULE.
In the PAI, POH, and POV events, you can use the statement to call any dialog module in the
ABAP program that has been defined using
MODULE <mod> [INPUT].
...
ENDMODULE.
It is technically possible to have two dialog modules with the same name in the same program,
one defined using OUTPUT, the other with INPUT. However, this is not recommended.
Since dialog modules in an ABAP program can be called from more than one screen, you can
program functions that you need in several screens centrally in a single module. For example, it
is usual to copy the contents of the OK-code field into an auxiliary variable and then reset the
field in all PAI events. You could program this task in a single module that you would then call
from the PAI event of all screens.
If you need to distinguish between screen numbers in a dialog module, you can use the system
field SY-DYNNR, which always contains the number of the current screen. This would allow you,
for example, to analyze the function code in a single PAI module and then control the further
program flow according to the screen number and function code.
The screen display is prepared in the PBO event. The flow logic calls the corresponding ABAP
dialog modules. Then, the screen is displayed. When this happens, control passes from the
application server to the SAPgui. The screen accepts user input until the user triggers the PAI
event. The control then returns to the application server. The program processes user input by
calling the corresponding ABAP dialog modules. After the PAI processing is complete, the PBO
processing of the next screen starts. The PAI processing and the PBO processing of the next
screen form a single dialog step on the application server. The current screen remains visible
until the PBO of the next screen is complete, but is not ready for input.
There are various ways of calling the dialog modules in the flow logic. The syntax of the flow
logic allows you to call dialog modules conditionally, and to control the transfer of data between
the screen and the ABAP program.
Simple Module Calls
To call a module, use the flow logic statement
MODULE <mod>.
The system starts the module <mod>, which must have been defined for the same event block in
which the call occurs.
If you only use simple modules in the screen flow logic, the data transport between the ABAP
program and the screen is as follows:
 _ In the PAI event, all of the data from the screen is transported to the ABAP program (as
long as there are program fields with the same names as the screen fields) after the
automatic input checks [Page 577] and before the first PAI module is called. This
includes the contents of the system fields (for example, SY-UCOMM, which contains the
current function code).
 _ At the end of the last PBO module, and before the screen is displayed, all of the data is
transported from the ABAP program to any identically-named fields in the screen.
PAI PBO
 Dialog step
 Data transport
Data is transported between the screen and the ABAP program at the beginning and end of each
dialog step on the application server. Do not confuse this with the data transport between a
screen on the application server and the SAPgui on the presentation server.
Simple module call

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_module.
TABLES sdyn_conn.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code,
wa_spfli TYPE spfli.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  MOVE-CORRESPONDING wa_spfli TO sdyn_conn.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  SET TITLEBAR '100'.
ENDMODULE.                    "STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CLEAR_OK_CODE INPUT
*----------------------------------------------------------------------*
MODULE clear_ok_code INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
ENDMODULE.                    "CLEAR_OK_CODE INPUT
*----------------------------------------------------------------------*
*  MODULE GET_DATA INPUT
*----------------------------------------------------------------------*
MODULE get_data INPUT.
  MOVE-CORRESPONDING sdyn_conn TO wa_spfli.
  CLEAR sdyn_conn.
ENDMODULE.                    "GET_DATA INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  CASE sy-dynnr.
    WHEN 0100.
      CASE save_ok.
        WHEN 'CANCEL'.
          LEAVE PROGRAM.
        WHEN 'DISPLAY'.
          PERFORM read_data.
        WHEN 'CLEAR'.
          CLEAR wa_spfli.
      ENDCASE.
    ENDMODULE.                    "USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
*&      Form  READ_DATA
*&---------------------------------------------------------------------*
FORM read_data.
  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.
ENDFORM.                    "READ_DATA

The statically-defined next screen for screen 100 is 100. It uses components of the
structure SDYN_CONN, copied [Ext.] from the ABAP Dictionary, and looks like this:
Airline
Flight number
From airport
From
To airport
To
Departure time
Duration 0:00
00:00:00
Arrival time 00:00:00
Delete entries
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_100.
MODULE STATUS_0100.
PROCESS AFTER INPUT.
MODULE CLEAR_OK_CODE.
MODULE GET_DATA.
MODULE USER_COMMAND_0100.
In the GUI status STATUS_100, the symbol (F12) is active with the function code
CANCEL, and the functions DISPLAY and CLEAR are assigned to the function keys
F5 and shift+F2 respectively.
The program has a similar function to the example program in the section Processing
Input/Output Fields [Page 537].
Controlling the Data Transfer
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 <f> into 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 FIELD statement is executed, any value that you assign
to it is not overwritten.
The FIELD statement has further functions in connection with conditional module calls
Controlling the data transfer

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_field_chain.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code,
box1, box2, box3, box4,
mod1_result1, mod1_result2, mod1_result3, mod1_result4,
mod2_result1, mod2_result2, mod2_result3, mod2_result4,
mod3_result1, mod3_result2, mod3_result3, mod3_result4.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
  CLEAR: box1, box2, box3, box4.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'CANCEL'.
    LEAVE PROGRAM.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_1 INPUT
*----------------------------------------------------------------------*
MODULE module_1 INPUT.
  mod1_result1 = box1.
  mod1_result2 = box2.
  mod1_result3 = box3.
  mod1_result4 = box4.
ENDMODULE.                    "MODULE_1 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_2 INPUT
*----------------------------------------------------------------------*
MODULE module_2 INPUT.
  mod2_result1 = box1.
  mod2_result2 = box2.
  mod2_result3 = box3.
  mod2_result4 = box4.
ENDMODULE.                    "MODULE_2 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_3 INPUT
*----------------------------------------------------------------------*
MODULE module_3 INPUT.
  mod3_result1 = box1.
  mod3_result2 = box2.
  mod3_result3 = box3.
  mod3_result4 = box4.
ENDMODULE.                    "MODULE_3 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Field 1
Field 2
Field 3
Field 4
Module: 1 2 3
The screen fields BOX1, BOX2, BOX3, and BOX4 are 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 (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:
Field 1
Field 2
Field 3
Field 4
Module: 1 2 3
X
X
X
X X X
X
 _ The screen field BOX4 is transported in the PAI event, since it does not occur in any FIELD
statements.
   _ BOX2 is not transported until before the dialog module MODULE_2, and is therefore not
available in USER_COMMAND_0100 or MODULE_1.
 _ BOX1 and BOX3 are transported before dialog module MODULE_3, and are therefore only
available in that module.
Calling Modules Unconditionally
In the PAI event, the PAI modules are called in the sequence in which they occur in the screen
flow logic, after the automatic field checks [Page 577]. This means that the input on the screen
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 the
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 avoid this, you can use special function codes with a special module
call, which calls the module regardless of what the user enters on the screen.
Type E Function Codes
You can assign the function type E to the function codes of both pushbuttons on the screen and
of elements in the GUI status. To do this for a pushbutton, set the Function type attribute in the
Screen Painter to E. To do it in the GUI status, choose Goto _ Object lists _ Function list in the
Menu Painter, select the required function codes, and enter E for the function type.
If the user chooses a pushbutton or a function in the status, the system bypasses the automatic
field checks and calls a special module in the screen 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 Back (F3), Exit (Shift + F3), and Cancel (F12) usually have type E.
Calling a PAI Module for Type E Functions
When the user chooses a function with type E, the screen flow logic jumps directly to the
following statement:
MODULE <mod> AT EXIT-COMMAND.
Regardless of where it occurs in the screen 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, the contents of the OK-CODE field are transported to the ABAP field with the same
name. However, no other screen fields are transported to the program at this stage. If you
have 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.
PAI Modules for Type E Functions
The MODULE ... AT EXIT-COMMAND statement is normally used to leave the current screen
without the automatic input checks taking place. You should therefore program it to contain an
appropriate variant of the LEAVE statement, to leave the current screen, the call chain, or the
entire program, as appropriate. If the module does not leave the screen, 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 screen back to the program according
to the sequence defined in the FIELDS statements.
Unconditional module call

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_at_exit_command.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE ok_code,
input1(20), input2(20).
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  MESSAGE i888(bctrain) WITH text-001 ok_code input1 input2.
  IF ok_code = 'CANCEL'.
    CLEAR ok_code.
    LEAVE PROGRAM.
  ENDIF.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE BACK INPUT
*----------------------------------------------------------------------*
MODULE back INPUT.
  MESSAGE i888(bctrain) WITH text-002 ok_code input1 input2.
  IF ok_code = 'BACK'.
    CLEAR: ok_code, input1, input2.
    LEAVE TO SCREEN 100.
  ENDIF.
ENDMODULE.                    "BACK INPUT
*----------------------------------------------------------------------*
*  MODULE EXECUTE1 INPUT
*----------------------------------------------------------------------*
MODULE execute1 INPUT.
  MESSAGE i888(bctrain) WITH text-003 ok_code input1 input2.
  save_ok = ok_code.
  CLEAR ok_code.
ENDMODULE.                    "EXECUTE1 INPUT
*----------------------------------------------------------------------*
*  MODULE EXECUTE2 INPUT
*----------------------------------------------------------------------*
MODULE execute2 INPUT.
  MESSAGE i888(bctrain) WITH text-004 ok_code input1 input2.
  IF save_ok = 'EXECUTE'.
    MESSAGE s888(bctrain) WITH text-005.
  ENDIF.
ENDMODULE.                    "EXECUTE2 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Input field 1
Input field 2
Execute Cancel
?
?
The input fields have the names INPUT1 and INPUT2, and are obligatory fields. The
function codes of the pushbuttons are EXECUTE and CANCEL. CANCEL has
function type E.
In the GUI status STATUS_100, the back (F3) and cancel (F12) icons are
activated with the function codes BACK and CANCEL respectively. Both have the
function type E. The function code EXECUTE is assigned to the function key F8. It
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 obligatory fields, the automatic field check
displays an error message.
 _ If the user fills out the obligatory fields and then chooses Execute, all of the screen 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 obligatory fields. The CANCEL module
terminates the program.
 _ 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 obligatory fields. However, the program
does not terminate, since the function code is BACK. Instead, the automatic field checks are
performed. If the obligatory fields are filled, the modules EXECUTE1 and EXECUTE2 are
called.
The BACK module is never called, since only the first module with the AT EXITCOMMAND
addition is ever called. In the above example, the function code BACK
should be processed in the CANCEL module. Then, since there is only one module
statement with the AT EXIT-COMMAND addition, the position of the statement is
irrelevant.
Conditional Module Calls
Simple module calls are processed in the sequence in which they appear in the screen flow logic.
However, the syntax of the screen language also allows you to make PAI module calls
dependent on certain conditions by using the MODULE statement together with the FIELD
statement. You can apply conditions to both single fields and groups of fields. Conditional
module calls can help you to reduce the runtime of your program, particularly with modules that
communicate with database tables.
Conditions for Single Screen Fields
You can ensure that a PAI module is only called when a certain condition applies by using the
following statement:
FIELD <f> MODULE <mod> ON INPUT|REQUEST|*-INPUT.
The additions have the following effects:
 _ ON INPUT
The ABAP module is called only if the field contains a value other than its initial value.
This initial value is determined by the data type of the field: Space for character fields,
zero for numeric fields. Even if the user enters the initial value of the screen as the initial
value, the module is not called. (ON REQUEST, on the other hand, does trigger the call
in this case.)
 _ ON REQUEST
The module <mod> is only called if the user has entered something in the field. This
includes cases when the user overwrites an existing value with the same value, or
explicitly enters the initial value.
In general, the ON REQUEST condition is triggered through any form of "manual input".
As well as user input, the following additional methods of entering values also call the
module:
- The element attribute PARAMETER-ID (SPA/GPA parameters).
- The element attribute HOLD DATA
- CALL TRANSACTION ... USING
- Automatic settings of particular global fields
_ ON *-INPUT
The ABAP module is called if the user has entered a "*" in the first character of the field,
and the field has the attribute *-entry in the Screen Painter. When the input field is
passed to the program, the * is removed. * behaves like an initial field in the ON INPUT
condition.
The functions of the FIELD statement for controlling data transport [Page 565] also apply when
you use MODULE.
Conditions for Multiple Screen Fields
To ensure that one or more PAI modules are only called when several screen fields meet a
particular condition, you must combine the calls in the flow logic to form a processing chain. You
define processing chains as follows:
CHAIN.
...
ENDCHAIN.
All flow logic statements between CHAIN and ENDCHAIN belong to a processing chain. The
fields in the various FIELD statements are combined, and can be used in shared conditions.
CHAIN.
FIELD: <f1>, <f2>,...
MODULE <mod1> ON CHAIN-INPUT|CHAIN-REQUEST.
FIELD: <g1>, <g2>,...
MODULE <mod2> ON CHAIN-INPUT|CHAIN-REQUEST.
...
ENDCHAIN.
The additions ON CHAIN-INPUT and ON CHAIN-REQUEST work like the additions ON INPUT
and ON REQUEST that you use for individual fields. The exception is that the module is called
whenever at least one of the fields listed in a preceding FIELD statement within the chain meets
the condition. So <mod1> is called when one of the fields <fi> meets the condition. <mod2> is
called when one of the fields <fi> or <gi> meets the condition.
Within a processing chain, you can combine individual FIELD statements with a MODULE
statement to set a condition for a single field within the chain:
CHAIN.
FIELD: <f1>, <f2>,...
FIELD <f> MODULE <mod1> ON INPUT|REQUEST|*-INPUT
|CHAIN-INPUT|CHAIN-REQUEST.
MODULE <mod2> ON CHAIN-INPUT|CHAIN-REQUEST.
ENDCHAIN.
The module <mod1> is called when screen field <f> meets the specified condition for individual
fields. <mod2> is called when one of the fields <fi> or <f> meets the condition. If you use the
addition ON CHAIN-INPUT or ON CHAIN-REQUEST with FIELD <f>, the condition also applies
to the entire chain and module <mod1> and <mod2> are both called.
In cases where you apply conditions to various combinations of screen fields, it is worth setting
up a separate processing chain for each combination and calling different modules from within it.
The functions of the FIELD statement for controlling data transport [Page 565] also apply when
you use processing chains. Within a processing chain, screen fields are not transported until the
FIELD statement. Processing chains also have another function for the FIELDS statements that
they contain. This is described in the section on validity checks [Page 577].
Calling Modules after Cursor Selection
You can specify that a module should only be called if the cursor is positioned on a particular
screen element. To do this, use the statement
MODULE <mod> AT CURSOR-SELECTION.
The module <mod> is called whenever the function code of the user action is CS with function
type S. If you use this statement, it is best to assign the function code CS to function key F2. This
also assigns it to the mouse double-click.
The module is called in the sequence in which it occurs in the flow logic. It does not bypass the
automatic input checks. Data is transported from screen fields in the order in which it is defined
by the FIELD statements. The function code is empty, and neither SY-UCOMM nor the
OK_CODE field is affected. You can also combine this MODULE statement with the FIELD
statement:
FIELD <f> MODULE <mod> AT CURSOR-SELECTION.
or, for more than one field:
CHAIN.
FIELD: <f1>, <f2>,...
MODULE <mod> AT CURSOR-SELECTION.
ENDCHAIN.
The module <mod> is only called if the cursor is positioned on an input/output field <f> or an
input/output field <fi> in the processing chain. You can only apply this statement to input/output
fields.
The call hierarchy of the different combinations is as follows:
 _ If a MODULE... AT CURSOR-SELECTION statement is executed that was combined
with FIELD, a statement without FIELD is not executed.
 _ If a statement using FIELD appears more than once for the same screen field <f>, only
the first statement is executed.
 _ If a statement without FIELD occurs more than once, only the last statement is executed.
It is irrelevant whether the statements occur within a CHAIN ... ENDCHAIN block or not.
Conditional module calls

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_on_condition.
DATA: ok_code LIKE sy-ucomm,
input1(20), input2(20), input3(20),
fld(20).
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE CURSOR INPUT
*----------------------------------------------------------------------*
MODULE cursor INPUT.
  GET CURSOR FIELD fld.
  MESSAGE i888(bctrain) WITH text-001 fld.
ENDMODULE.                    "CURSOR INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_1 INPUT
*----------------------------------------------------------------------*
MODULE module_1 INPUT.
  MESSAGE i888(bctrain) WITH text-002.
ENDMODULE.                    "MODULE_1 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_2 INPUT
*----------------------------------------------------------------------*
MODULE module_2 INPUT.
  MESSAGE i888(bctrain) WITH text-003.
ENDMODULE.                    "MODULE_2 INPUT

ENDCHAIN.
MODULE CURSOR AT CURSOR-SELECTION.
The program uses information messages to show which modules are called following
user interaction and which data is transported.
 _ Whenever one of the input fields 1 or 2 is not initial, the system calls the module
MODULE_1 for any user interaction.
 _ Whenever one of the three input fields is changed, the system calls the module
MODULE_2 for any user interaction.
 _ Whenever input field 3 contains a * entry, the system calls module MODULE_* for any
user interaction.
 _ If the user chooses F2 or double-clicks a text field on the screen, the system calls the
module CURSOR.
 _ If the user chooses F2 or double-clicks input field 1, the system calls the module C1.
_ If the user chooses F2 or double-clicks input field 2 or 3, the system calls the module
CURSOR. Module C2 is never executed, since the MODULE ... AT CURSOR
SELECTION statement occurs twice, and only the last is processed.
Input Checks
It is normally necessary to check user input for validity and consistency. There are three kinds of
input checks on screens:
 _ Automatic Input Checks [Page 578]
Automatic input checks are called in the PAI event before data is transported back to the
ABAP program and before dialog modules are called.
 _ Input Checks in the Flow Logic [Page 581]
Input checks in the flow logic can be performed before you call dialog modules.
 _ Input Checks in Dialog Modules [Page 584]
These input checks are programmed in PAI modules. If the user enters an incorrect
value, you can make input fields ready for input again without repeating the PBO
processing.
Automatic Input Checks
In the PAI event, the screen makes a series of automatic input checks. These are carried out
before any data is transferred to the ABAP program, and before the screen flow logic is
processed. Before the automatic input checks, you can call a single dialog module
unconditionally [Page 568] using a special function type. You normally use this dialog module to
bypass the checks and leave the screen directly.
If the automatic input checks find an error, a message appears in the status bar of the screen,
and the corresponding fields remain ready for input. The user must correct the entries and
trigger the PAI again. The actual PAI processing does not start until there are no more errors.
The automatic input checks run in the following order:
Mandatory Fields
If a field is defined as a mandatory field in the Screen Painter, the user must enter a value for it
before the PAI processing can start.
Input Format
The values entered in the input fields on the screen must correspond to the data format of the
corresponding screen field. For example, the format of a date field (type DATS) is eight
characters and has the format YYYYMMDD. All of the characters must be numeric. MM must be
12 or less, and DD must be 31 or less. The system also checks that the specified day is valid for
the month.
ABAP Dictionary Checks
If you create an input field in the Screen Painter by copying [Ext.] a ABAP Dictionary field, the
screen checks whether:
 _ The value satisfies any foreign key relationship to another database table, that is, the
system checks whether the value is contained in the check table as a foreign key [Ext.].
This is only checked if the Foreign key attribute is set in the Screen Painter for the input
field. The input check is not necessarily identical with the input help [Page 595]. The
programmer is responsible for ensuring that the input help presents values that will all
pass any foreign key check.
 _ That the value is one of the fixed values of the domain [Ext.] of the fields, that is, the
system checks the definition of the underlying domain in the ABAP Dictionary. The fixed
values of the domain can also be used as input help [Page 595]. However, the value
table of a domain is not checked. It is only used as a default value for the check tables
of the fields that refer to the domain.
Automatic input checks

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_automatic_checks.
DATA: ok_code LIKE sy-ucomm,
date TYPE d.
TABLES sdyn_conn.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE PAI INPUT
*----------------------------------------------------------------------*
MODULE pai INPUT.
  MESSAGE i888(bctrain) WITH text-001.
ENDMODULE.                    "PAI INPUT

The next screen (statically defined) for screen 100 is 100. It has the following layout:
Airline
Flight number
Execute
Selection
Date ?
?
?
?
The date field DATE from the program is assigned to the input field Date. The other
input fields are the CARRID; CONNID, and MARK components of the ABAP
Dictionary structure SDYN_CONN. All of the fields are mandatory. The function
code of the pushbutton is EXECUTE.
In the GUI status STATUS_100, the icon (F12) is active with function code
CANCEL and function type E. Furthermore, the function key F8 is assigned to the
function code EXECUTE.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_100.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE PAI.
The user must fill all of the input fields with valid values before the PAI module can
be called:
_ All of the input fields must contain values
_ The date entry must have the correct format
_ The airline must be in the check table SCARR
_ The flight number must exist for the corresponding airline in the check table SPFLI
_ The selection MARK must be one of the fixed values of the domain S_FLAG.
The user can leave the screen using Cancel ( , F12) without entering all values
correctly, since the module call is programmed using AT EXIT-COMMAND.
Checking Fields in the Screen Flow Logic
There are two special variants of the FIELD statement that you can use in PAI processing to
check the values of screen fields. However, this method is obsolete and should no longer be
used. It is only supported for compatibility reasons.
Checking a Value List
You can check a screen field against a value list as follows:
FIELD <f> VALUES (<v1>, <v2>,...).
The individual entries <vi> in the list can have the following format:
_ [NOT] <val>
_ [NOT] BETWEEN <val1> AND <val2>
You can check against single fields <val> or intervals between <val1> and <val2>. The
comparison fields must have the data type CHAR or NUMC, must be enclosed in inverted
commas, and must be written in uppercase. If the check fails, an error message is displayed and
the corresponding field is again ready for entry.
The input help [Page 595] for <f> can also use the value list in the FIELD statement. This helps
the user to enter only correct values.
The functions of the FIELD statement for controlling data transport [Page 565] also apply when
you use the VALUES addition.
Checking Against Database Tables
You can check a screen field against the contents of a database table as follows:
FIELD <f> SELECT *
FROM <dbtab>
WHERE <k1> = <f1> AND <k2> = <f2> AND...
[INTO <g>]
WHENEVER [NOT] FOUND SEND ERRORMESSAGE|WARNING
[<num> [WITH <h1>... <h4>]].
This combines the FIELD statement with a SELECT statement. The syntax of the SELECT
statement must be entered exactly as shown above. In particular, the WHERE condition may not
contain relational operators of the type 'EQ'. In the WHERE condition, the fields of the primary
key <ki> of the database table <dbtab> are checked against the screen fields <fi>. If a matching
entry is found, you can write it into a screen field <g>, but you do not have to. You can also send
an error or warning message depending on the outcome of the search, which makes the input
field for <f> ready for input again.
<num> allows you to specify a message number from the message class specified in the
MESSAGE-ID of the first statement in the program. In this case, the message class can only be
two characters long. If you do not specify a message class, the system displays a default
message. If you use WITH, you can pass literals or screen fields to any placeholderse (&) within
the message.
The input help [Page 595] for <f> can also use the value list in the FIELD statement. This helps
the user to enter only correct values.
You can also use the SELECT statement in screen flow logic without combining it with the FIELD
statement. This allows you to fill screen fields with the contents of database tables without calling
ABAP modules. The functions of the FIELD statement for controlling data transport [Page 565]
also apply when you use SELECT.
Checking Fields in the Screen Flow Logic

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_value_select MESSAGE-ID at.
DATA: ok_code LIKE sy-ucomm,
carrier TYPE spfli-carrid,
connect TYPE spfli-connid.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_0100 OUTPUT.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_1 INPUT
*----------------------------------------------------------------------*
MODULE module_1 INPUT.
  MESSAGE i888(bctrain) WITH text-001 carrier
  text-002 connect.
ENDMODULE.                    "MODULE_1 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_2 INPUT
*----------------------------------------------------------------------*
MODULE module_2 INPUT.
  MESSAGE i888(bctrain) WITH text-001 carrier
  text-002 connect.
ENDMODULE.                    "MODULE_2 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Airline
Flight number
Execute
The program fields CARRIER and CONNECT are assigned to the input fields. The
function code of the pushbutton is EXECUTE.
In the GUI status STATUS_100, the icon (F12) is active with function code
CANCEL and function type E. Furthermore, the function key F8 is assigned to the
function code EXECUTE.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_0100.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
FIELD CARRIER VALUES (NOT 'AA', 'LH', BETWEEN 'QF' AND 'UA').
MODULE MODULE_1.
FIELD CONNECT SELECT *
FROM SPFLI
WHERE CARRID = CARRIER AND CONNID = CONNECT
WHENEVER NOT FOUND SEND ERRORMESSAGE 107
WITH CARRIER CONNECT.
MODULE MODULE_2.
The user must enter a value of CARRIER that is in the list following VALUES before
MODULE_1 is called. When MODULE_1 is called, CONNECT has not yet been
transported.
Next, the user can only enter a value for CONNECT that exists in the database table
SPFLI as part of a primary key together with CARRIER. If not, error message 107
from message class AT is displayed in the status bar:
E: Unable to find any entries for key & &.
CONNECT is not transported, and module MODULE_2 not called until the user has
entered a correct value.
Input Checks in Dialog Modules
You cannot perform input checks in PAI modules of programs until you have transported the
contents of the input fields to the ABAP program. You can then use logical expressions [Page
225] to check the values that the user entered. You should then allow the user to correct any
wrong entries before calling further modules.
You can do this by sending warning (type W) or error (type E) messages [Page 927] from PAI
modules that are called in conjunction with the ABAP statements FIELD and CHAIN.
Checking Single Fields
If you send a warning or error message from a module <mod> that you called using a FIELD
statement as follows:
FIELD <f> MODULE <mod>.
the corresponding input field on the current screen (and only this field) is made ready for input
again, allowing the user to enter a new value. If the field is only checked once, the PAI
processing continues directly after the FIELD statement, and the preceding modules are not
called again.
Checking a Set of Fields
If you send a warning or error message from a module <mod> that you called using a FIELD
statement as follows:
CHAIN.
FIELD: <f1>, <f2>,...
MODULE <mod1>.
FIELD: <g1>, <g2>,...
MODULE <mod2>.
...
ENDCHAIN.
all of the fields on the screen that belong to the processing chain (all of the fields listed in the field
statements) are made ready for input again. Other fields are not ready for input. Whenever the
MODULE statement appears within a processing chain, even if there is only one FIELD attached
to it, all of the fields in the chain (not only the affected field) are made ready for input again,
allowing the user to enter new values. If the fields in the processing chain are only checked
once, the PAI processing continues directly after the FIELD statement, and the preceding
modules are not called again.
Controlling Input and Data Transport
If you use the FIELD statement outside a chain, only a single field is made ready for input when a
warning or error message is displayed. If you use it between the CHAIN and ENDCHAIN
statements, it controls a set of fields. All of the fields controlled by a FIELD statement are
transported back to the screen, bypassing PBO processing. This means that any changes made
to the field contents before the message become visible on the screen. This also applies to
information
Checking Fields Repeatedly
You may sometimes need to include the same field in more than one FIELD or CHAIN statement.
If one of the corresponding modules sends a warning or error message, PAI processing resumes
with the value that the user corrected. However, in this case, processing cannot simply resume at
the corresponding FIELD or CHAIN statement if the field in question has already been included in
an earlier FIELD or CHAIN statement.
Instead, all of the FIELD and CHAIN statements containing a field in which an error occurred are
repeated. PAI processing resumes at the first FIELD or CHAIN statement containing a field in
which an error occurred and that the user changed the last time the screen was displayed.
Example:
PROCESS AFTER INPUT.
FIELD F1 MODULE M1.
FIELD F2 MODULE M2.
CHAIN.
FIELD: F1, F2, F3.
FIELD: F4, F5, F1.
MODULE M3.
MODULE M4.
ENDCHAIN.
CHAIN.
FIELD: F6.
MODULE M5.
ENDCHAIN.
CHAIN.
FIELD F4.
MODULE M6.
ENDCHAIN.
If module M6 contains a warning or error message, the screen is displayed again, after which
processing resumes with the first CHAIN statement and module M3, since this is the first
occurrence of the field F4.
Remaining Functions in the FIELD Statement
All of the functions of the FIELD and CHAIN statements for controlling data transport [Page 565]
and conditional module calls [Page 572] can also be used in combination with warning and error
messages. The contents of each field are transported at the FIELD statement in which the field
occurs. If a warning or error message occurs in a conditional module of a processing chain, all of
the fields in that chain will be ready for input when the screen is redisplayed, although not all of
the fields will have been transported.
If a warning or error message occurs in a module that is not linked with a FIELD or CHAIN
statement, none of the fields on the screen will be ready for input. In this case, the user can only
exit the program, but only as long as you have included an unconditional module call [Page 568]
in the program.
Input Checks in Dialog Modules

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
PROGRAM demo_dynpro_field_chain.
DATA: ok_code LIKE sy-ucomm,
input1 TYPE i, input2 TYPE i, input3 TYPE i,
input4 TYPE i, input5 TYPE i, input6 TYPE i,
sum TYPE i.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
MODULE init_screen_100 OUTPUT.
  CLEAR: input1, input2, input3, input4, input5, input6.
  SET PF-STATUS 'STATUS_100'.
ENDMODULE.                    "INIT_SCREEN_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_1 INPUT
*----------------------------------------------------------------------*
MODULE module_1 INPUT.
  IF input1 < 50.
    MESSAGE e888(bctrain) WITH text-001 '50' text-002.
  ENDIF.
ENDMODULE.                    "MODULE_1 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_2 INPUT
*----------------------------------------------------------------------*
MODULE module_2 INPUT.
  IF input2 < 100.
    MESSAGE e888(bctrain) WITH text-001 '100' text-002.
  ENDIF.
ENDMODULE.                    "MODULE_2 INPUT
*----------------------------------------------------------------------*
*  MODULE MODULE_3 INPUT
*----------------------------------------------------------------------*
MODULE module_3 INPUT.
  IF input3 < 150.
    MESSAGE e888(bctrain) WITH text-001 '150' text-002.
  ENDIF.
ENDMODULE.                    "MODULE_3 INPUT
*----------------------------------------------------------------------*
*  MODULE CHAIN_MODULE_1 INPUT
*----------------------------------------------------------------------*
MODULE chain_module_1 INPUT.
  IF input4 < 10.
    MESSAGE e888(bctrain) WITH text-003 '10' text-002.
  ENDIF.
ENDMODULE.                    "CHAIN_MODULE_1 INPUT
*----------------------------------------------------------------------*
*  MODULE CHAIN_MODULE_2 INPUT
*----------------------------------------------------------------------*
MODULE chain_module_2 INPUT.
  CLEAR sum.
  sum = sum + : input4, input5, input6.
  IF sum <= 100.
    MESSAGE e888(bctrain) WITH text-004 '100' text-002.
  ENDIF.
ENDMODULE.                    "CHAIN_MODULE_2 INPUT
*----------------------------------------------------------------------*
*  MODULE EXECUTION INPUT
*----------------------------------------------------------------------*
MODULE execution INPUT.
  MESSAGE i888(bctrain) WITH text-005.
ENDMODULE.                    "EXECUTION INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Input field 1
Input field 2
Execute
Input field 3
Input field 4
Input field 5
Input field 6
The screen fields INPUT1 to INPUT6 are assigned to the input fields. The function
code of the pushbutton is EXECUTE.
In the GUI status STATUS_100, the icon (F12) is active with function code
CANCEL and function type E. Furthermore, the function key F8 is assigned to the
function code EXECUTE with the function type <blank>.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_SCREEN_100.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
FIELD INPUT1 MODULE MODULE_1.
FIELD INPUT2 MODULE MODULE_2.
FIELD INPUT3 MODULE MODULE_3.
CHAIN.
FIELD INPUT4.
MODULE CHAIN_MODULE_1.
FIELD INPUT5.
FIELD INPUT6 MODULE CHAIN_MODULE_2.
ENDCHAIN.
MODULE EXECUTION.
This program demonstrates how you can check input fields in dialog modules.
The fields INPUT1 to INPUT3 are checked independently of each other in the
modules MODULE_1 to MODULE_3. As long as the user does not enter a
corresponding value, the screen is repeatedly displayed with the appropriate field
ready for input.
The fields INPUT4 to INPUT6 are checked together in a processing chain. If
INPUT4 does not satisfy the condition in CHAIN_MODULE_1, all three fields are
again ready for input. The same applies if the three fields do not satisfy the condition
in CHAIN_MODULE_2.
The EXECUTION module, from which an information message is displayed, is not
executed until all six fields satisfy the appropriate conditions.
Field Help, Input Help, and Dropdown Boxes
Field help (F1) and input help (F4) are standard functions throughout the system. You therefore
cannot assign any other function codes to the F1 or F4 keys.
 _ If the user chooses the F1 key or the corresponding help icon ( ), a help text appears
for the field in which the cursor is currently positioned.
 _ If the user chooses F4 or the input help button ( ) to the right of a screen field, a list of
possible entries appears for the cursor in which the cursor is currently positioned. The
user can then choose one or more values, which are then copied into the screen field.
There are various ways of making field and input help available to users. For example, you can
either use ABAP Dictionary functions, or program your own help functions.
Another special way to display lists of values is to use a dropdown box.
Field Help
There are three ways of displaying field help for screen elements:
Data Element Documentation
If you place a field on the screen in the Screen Painter by copying [Ext.] a ABAP Dictionary field,
the corresponding data element documentation from the ABAP Dictionary is automatically
displayed when the user chooses field help (as long as the help has not been overridden in the
screen flow logic).
For further information about creating data element documentation, refer to data elements [Ext.].
Data Element Supplement Documentation
If the data element documentation is insufficient, you can expand it by writing a data element
supplement
Data element supplement documentation contains the heading Definition, as well as the following
others:
_ Use
_ Procedure
_ Examples
_ Dependencies
To create data element supplement documentation for a screen, choose Goto _ Documentation
_ DE supplement doc. from the element list of the screen. A dialog box appears in which the
system proposes a number as the identified for the data element supplement. You can then enter
help texts for the above headings using the SAPscript editor.
Data element supplement documentation created in this way is program- and screen-specific.
Any data element supplement documentation created in the ABAP Dictionary with the same
number is overridden by the screen-specific documentation. You can link existing data element
supplement documentation created in the ABAP Dictionary with a screen field by using the table
THLPF. To do this, crate a new row in THLPF containing the following data: Program name,
screen name, field name, and number of the data element supplement documentation.
To display data element supplement documentation, you must code the following screen flow
logic in the POH event:
PROCESS ON HELP-REQUEST.
...
FIELD <f> [MODULE <mod>] WITH <num>.
...
After PROCESS ON HELP-REQUEST, you can only use FIELD statements. If there is no
PROCESS ON HELP-REQUEST keyword in the flow logic of the screen, the data element
documentation for the current field, or no help at all is displayed when the user chooses F1.
Otherwise, the next FIELD statement containing the current field <f> is executed.
If there is screen-specific data element supplement documentation for the field <f>, you can
display it by specifying its number <num>. The number <num> can be a literal or a variable. The
variable must be declared and filled in the corresponding ABAP program.
You can fill the variables, for example, by calling the module <mod> before the help is displayed.
However, the FIELD statement does not transport the contents of the screen field <f> to the
ABAP program in the PROCESS ON HELP-REQUEST event.
Calling Help Texts from Dialog Modules
If data element supplement documentation is insufficient for your requirements, or you want to
display help for program fields that you have not copied from the ABAP Dictionary, you can call
dialog modules in the POH event:
PROCESS ON HELP-REQUEST.
...
FIELD <f> MODULE <mod>.
...
After the PROCESS ON HELP-REQUEST statement, you can only use the MODULE statement
together with the FIELD statement. When the user chooses F1 for a field <f>, the system calls
the module <mod> belonging to the FIELD <f> statement. If there is more than one FIELD
statement for the same field <f>, only the first is executed. However, the contents of the screen
field <f> are not available in the module <mod>, since it is not transported by the FIELD
statement during the PROCESS ON HELP-REQUEST event. The field help should not be
dependent on the user input.
The module <mod> is defined in the ABAP program like a normal PAI module. The processing
logic of the module must ensure that adequate help is displayed for the field in question. Instead
of calling an extra screen with text fields, you should use one of the following function modules to
display a suitable SAPscript document:
 _ HELP_OBJECT_SHOW_FOR_FIELD
This function module displays the data element documentation for components of any
structure or database table from the ABAP Dictionary. You pass the name of the
component and structure or table to the import parameters FIELD and TABLE.
 _ HELP_OBJECT_SHOW
Use this function module to display any SAPscript document. You must pass the
document class (for example, TX for general texts, DE for data element documentation)
and the name of the document to the import parameters DOKCLASS and DOKNAME.
For technical reasons, you must also pass an empty internal table with the line type
TLINE to the tables parameter of the function module.
For further information about how to create SAPscript documents, refer to the Documentation of
System Objects [Ext.] documentation.
Field help on screens.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_f1_help.
DATA: text(30),
var(4),
int TYPE i,
links TYPE TABLE OF tline,
field3, field4.
TABLES demof1help.
text = text-001.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE F1_HELP_FIELD2 INPUT
*----------------------------------------------------------------------*
MODULE f1_help_field2 INPUT.
  int = int + 1.
  CASE int.
    WHEN 1.
      var = '0100'.
    WHEN 2.
      var = '0200'.
      int = 0.
  ENDCASE.
ENDMODULE.                    "F1_HELP_FIELD2 INPUT
*----------------------------------------------------------------------*
*  MODULE F1_HELP_FIELD3 INPUT
*----------------------------------------------------------------------*
MODULE f1_help_field3 INPUT.
  CALL FUNCTION 'HELP_OBJECT_SHOW_FOR_FIELD'
    EXPORTING
      doklangu         = sy-langu
      doktitle         = text-002
      called_for_tab   = 'DEMOF1HELP'
      called_for_field = 'FIELD1'.
ENDMODULE.                    "F1_HELP_FIELD3 INPUT
*----------------------------------------------------------------------*
*  MODULE F1_HELP_FIELD4 INPUT
*----------------------------------------------------------------------*
MODULE f1_help_field4 INPUT.
  CALL FUNCTION 'HELP_OBJECT_SHOW'
    EXPORTING
      dokclass = 'TX'
      doklangu = sy-langu
      dokname  = 'DEMO_FOR_F1_HELP'
      doktitle = text-003
    TABLES
      links    = links.
ENDMODULE.                    "F1_HELP_FIELD4 INPUT

The next screen (statically defined) for screen 100 is 100. It has the following layout:
Field 1
Field 2
Cancel
Field 3
Field 4
Data element documentation
Data element supplement documentation
Any data element documentation
Any documentation
The screen fields DEMOf1HELP-FIELD1 and DEMOF1HELP-FIELD2 from the
ABAP Dictionary and the program fields FIELD3 and FIELD4 are assigned to the
input fields. The pushbutton has the function code CANCEL with function type E.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
PROCESS ON HELP-REQUEST.
FIELD DEMOF1HELP-FIELD2 MODULE F1_HELP_FIELD2 WITH VAR.
FIELD FIELD3 MODULE F1_HELP_FIELD3.
FIELD FIELD4 MODULE F1_HELP_FIELD4.
The components FIELD1 and FIELD2 of structure DEMOF1HELP both refer to the
data element DEMOF1TYPE. This data element is documented, and also has two
supplements with numbers 0100 and 0200.
The following field help is displayed:
 _ When the user chooses F1 on the input field for DEMOF1HELP-FIELD1, the data
element documentation for DEMOF1TYPE is displayed, since the field does not occur in
the PROCESS ON HELP-REQUEST event.
 _ If the user chooses F1 repeatedly for the input field DEMOF1HELP-FIELD2, the data
element documentation is displayed, along with the supplement documentation for either
0100 or 0200 alternately. The variable VAR is filled in the dialog module
F1_HELP_FIELD2.
 _ When the user chooses F1 on the input field for FIELD3, the data element
documentation for DEMOF1TYPE is displayed, since this is called in the dialog module
F1_HELP_FIELD3 by the function module HELP_OBJECT_SHOW_FOR_FIELD.
 _ When the user chooses F1 on the input field for FIELD4, the SAPscript documentation
DEMO_FOR_F1_HELP is displayed, since this is called in the dialog module
F1_HELP_FIELD4 by the function module HELP_OBJECT.
Input Help
One of the important features of screens is that they can provide users with lists of possible
entries for a field. There are three techniques that you can use to create and display input help:
1. Definition in the ABAP Dictionary
In the ABAP Dictionary, you can link search helps to fields. When you create screen
fields with reference to ABAP Dictionary fields, the corresponding search helps are then
automatically available. If a field has no search help, the ABAP Dictionary still offers the
contents of a check table, the fixed values of the underlying domain, or static calendar or
clock help.
2. Definition on a screen
You can use the input checks of the screen flow logic, or link search helps from the
ABAP Dictionary to individual screen fields.
3. Definition in dialog modules
You can call ABAP dialog modules in the POV event of the screen flow logic and
program your own input help.
These three techniques are listed in order of ascending priority. If you use more than one
technique at the same time, the POV module calls override any definition on the screen, which, in
turn, overrides the link from the ABAP Dictionary.
However, the order of preference for these techniques should be the order listed above. You
should, wherever possible, use a search help from the ABAP Dictionary, and only use dialog
modules when there is really no alternative. In particular, you should consider using a search
help exit to enhance a search help before writing your own dialog modules.
Input Help from the ABAP Dictionary
The main input help available from the ABAP Dictionary is in the form of search helps [Ext.].
Search helps are independent Repository objects that you create using the ABAP Dictionary.
They are used to present input help for screen fields. You can use link search helps to table
fields and data elements. As well as search helps, you can still, in exceptional cases, use check
tables, fixed values, or static input help.
Input Help Methods
 _ Search helps
There are two kinds of search helps: elementary and collective. An elementary search
help [Ext.] represents a search path. It defines the location of the data for the hit list, how
values are exchanged between the screen and the selection method, and the user dialog
that occurs when the user chooses input help. A collective search help [Ext.] consists of
two or more elementary search helps. Collective search helps cover a series of search
paths for a field, all of which could be useful. The collective search help is the interface
between the screen and the various elementary search helps.
 _ Check tables
The ABAP Dictionary allows you to define relationships between tables using foreign
keys [Ext.]. A dependent table is called a foreign key table, and the referenced table is
called the check table. Each key field of the check table corresponds to a field in the
foreign key table. These fields are called foreign key fields. One of the foreign key fields
is designated as the check field for checking the validity of values. The key fields of the
check table can serve as input help for the check field.
 _ Fixed values
You can restrict the values that a domain [Ext.] in the ABAP Dictionary may take by
assigning fixed values to it. The fixed values can be used as input help for the fields that
are defined using that domain. However, the value table of a domain is not used for
input help. It is only used as a default value for the check tables of the fields that refer to
the domain.
 _ Static input help
Fields with the types DATS and TIMS have their own predefined calendar and clock help
that can be used as input help.
Input Help Hierarchy in the ABAP Dictionary
There are various ways of linking search helps with fields of database tables or components of
structures. The input help available to a user depends on the type of link. The following list
shows, in ascending order of priority, the input help that is used:
1. Calendar and clock help
If no other input help has been defined for a field with type DATS or TIMS, the calendar
or clock help is displayed.
2. Domain fixed values
If a field has no check table or search help, any fixed values of the underlying domain are
used.
3. Search help of the data element
Search helps from the ABAP Dictionary can be attached to a data element [Ext.]. If a
field has no check table or search help of its own, the system uses the search help
assigned to the underlying data element.
4. Check table
If the check table has no text table and no search help of its own, and a field has no
search help of its own, the contents of the key fields of the check table are used as input
help.
5. Check table with text table
You can define a text table [Ext.] for a table. If the check table for a field has a text table
defined for it, the input help displays both the key fields from the check table and the
corresponding text from the text table in the user's logon language.
6. Check table with search help
Search helps can be attached to the check table [Ext.] of a field. The search help is
displayed with the values from the check table. However, it allows you to transfer the
values of more than one parameter.
7. Search help for a field
Search helps can also be directly attached to a field [Ext.] of a structure or a database
table. This has the highest priority, and is always displayed for input help. When you
attach the search help, you should therefore ensure that it only offers values that are also
in the check table, otherwise errors may occur in the automatic input checks [Page 578].
Search Helps and Value Transport
Search helps have an interface (search help parameters), which determines which entries,
already made by the user on the screen, should be used when compiling the hit list, and the
screen fields that should be filled when the user chooses an entry. The parameters of a search
help are divided into import and export parameters. Parameters can also be both import and
export parameters simultaneously.
When the user starts the input help, the contents of the fields on the screen are passed to the
import parameters of the search help. If a search help is assigned to a data element or directly to
a screen field, only one search help parameter is assigned to the field, and values are only
transported from the field to this parameter. If the search help is assigned to a table or structure
field, or to the check table of the field, there may be more than one parameter of the search help
that has to be filled with values. When the input help is started and the search help is assigned to
a table or structure field, the system tries to find a field with the same name as each import
parameter of the search help. Wherever it finds an identically-named field, the field contents are
transferred to the search help parameter.
When the user selects a line from the hit list of the search help, the system transfers values from
the export parameters of the search help to the corresponding screen fields. Values from the hit
list are only returned to fields on the screen that are linked with an export parameter of the
search help and are ready for input.
Changing Search Helps
In exceptional cases, you can modify the standard flow of an input help using a search help exit
[Ext.]. A search help exit is a function module with a predefined interface. You can call it at
defined points within the input help process. The search help exit allows you to store your own
program logic that either steers the subsequent processing or replaces it altogether.
The function module can change the attributes of the search help, the selection options that are
used to preselect the hit list, the hit list itself, and also the subsequent processing steps.
All search help exits must have the same interface as the function module
F4IF_SHLP_EXIT_EXAMPLE. However, you can define any number of additional optional
parameters, especially exporting parameters. For further information about the interface, refer to
the function module documentation.
If you have assigned a search help exit to a search help, it is called by the help processor at the
following points. They are the points at which the user can interact with the input help, since
these are the points at which you can best change the flow of the search help in the interests of
the user:
1. Before the dialog box for selecting the search path is displayed.
At the SELONE event (collective search helps only). This makes it possible to make the
search help dependent on the transaction, on other system variables, or even on the
state of the radio buttons on the screen. (This is the only event in which the search help
exit is called for collective search helps. All other events call the search help exit for the
selected elementary search help.)
2. After an elementary search help has been selected (event PRESEL1).
Here, you can change the assignment of the search help to the screen by, for example,
changing the way in which the search help parameters are assigned to screen fields.
3. Before the dialog box for entering search conditions is displayed.
(PRESEL event). This enables you to change the contents of the dialog box, or to
suppress it altogether.
4. Before data is selected
(SELECT event). Although the value selection contains no user interaction, it can still be
overridden either partially or fully by the search help exit. This may be necessary if it not
possible to read the data using a SELECT statement for a table or view.
5. Before the hit list is displayed
(DISP event). Here, you can affect how the hit list is displayed by, for example,
suppressing certain lines or columns of the list depending on the authorizations of the
user.
6. Before the line selected by the user is returned to the screen
(RETURN event). This can make sense if the subsequent flow of the transaction is to
depend on the value selected by the user. A typical use of this event would be to set
SPA/GPA parameters.
Certain search help functions are requested repeatedly in similar ways. One example of this is
the possibility to set the search help that will be used dynamically. Standard function modules
have been written for these cases, which you can use either directly as search help exits, or call
from within a search help exit. Such function modules all have the prefix F4UT_.
The Role of Domain Value Tables
Prior to Release 4.0, it was possible to use the value table of a domain to provide input help. This
is no longer possible, primarily because unexpected results could occur if the value table had
more than one key field. It was not possible to restrict the other key fields, which meant that the
environment of the field was not considered, as is normal with check tables.
In cases where this kind of value help was appropriate, you can reconstruct it by creating a
search help for the data elements that use the domain in question, and using the value table as
the selection method.
Example
Input help from the ABAP Dictionary.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_f4_help_dictionary.
TABLES demof4help.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Date
Time
Cancel
Airline
Flight number
Static calendar help
Check table with search help
Search help for field
Static time help
Selection Domain fixed values
Airline Search help for data element
00:00:00
The components of the ABAP Dictionary structure DEMOF4HELP are assigned to
the input fields. The pushbutton has the function code CANCEL with function type E.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
When the user chooses input help for the individual fields, the following is displayed:
_ The Date and Time fields refer to the components DATE_FIELD and TIME_FIELD
respectively of the ABAP Dictionary structure. These have the data type DATS and
TIMS, so the input help is a calendar and a clock respectively.
 _ The Selection field refers to the structure component MARK_FIELD. This has the
underlying domain S_FLAG, which has two fixed values. These are displayed as the
input help.
 _ The first Airline field refers to the structure component CARRIER1. This component has
the underlying data element DEMOF4DE, to which the search help parameter CARRID
of search help DEMO_F4_DE is assigned. The search help reads the columns CARRID
and CARRNAME from the database table SCARR. Only CARRNAME is listed, but
CARRID is flagged as an export parameter.
 _ The second Airline field refers to the structure component CARRIER2. This component
has the check table SCARR. The check table, in turn, has the search help H_SCARR
attached to it. This lists and exports the columns CARRID and CARRNAME.
   _ The Flight number field refers to the structure component CONNID. The search help
DEMO_F4_FIELD is assigned to it. The search help has two parameters CARRID and
CONNID, which are assigned to the components CARRIER2 and CONNID of the
structure. The search help imports CARRIER, reads the corresponding data from the
database table SPFLI, lists CARRIER and CONNID, and exports CONNID.
Input Help on the Screen
Within the Screen Painter, you can define two types of input help:
1. The FIELD statement with one of the additions VALUES or SELECT.
2. Linking a search help directly to a screen field.
If you link a search help directly to a screen field, it overrides the additions of the FIELD
statement. However, the input check [Page 581] functions of the FIELD statement remain
unaffected.
Input Help in Flow Logic
The following input help methods are obsolete and should not be used. They are still supported
for compatibility reasons.
In the screen flow logic, you can specify a value list for a screen field <f> as follows:
FIELD <f> VALUES (<val1>, <val2>,...).
The value list contains a series of single values <vali>. The NOT and BETWEEN additions for the
input check [Page 581] are not appropriate for input help.
You can also create a value list by accessing a database table as follows:
FIELD <f> SELECT *
FROM <dbtab>
WHERE <k1> = <f1> AND <k2> = <f2> AND...
In the WHERE condition, the fields of the primary key <ki> of the database table <dbtab> are
checked against the screen fields <fi>. The WHENEVER addition, used with input checks [Page
581], is not necessary for input help.
If you have used a ABAP Dictionary reference for field <f>, the selection and the hit list formatting
may be affected by any check table attached to the field.
Attaching a Search Help
Search helps from the ABAP Dictionary can be attached to a screen field [Ext.]. To do this, enter
the name of the search help in the corresponding field in the attributes of the screen field in the
Screen Painter. This assigns the first parameter of the search help to the screen field. It is only
possible to place a value from the hit list onto the screen.
Input help on a screen.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_f4_help_dynpro MESSAGE-ID at.
DATA: carrier(3) TYPE c,
connection(4) TYPE c.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Cancel
Airline
Flight number
Screen field with search help
Input help in the flow logic
The input fields have been adopted from the program fields CARRIER and
CONNECTION. The function code of the pushbutton is CANCEL, with function type
E. The search help DEMO_F4_DE with the search help parameter CARRID is
assigned to the screen field CARRIER. The search help uses the database table
SCARR.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
FIELD CARRIER VALUES ('AA', 'LH').
FIELD CONNECTION SELECT *
FROM SPFLI
WHERE CARRID = CARRIER
AND CONNID = CONNECTION.
When the user chooses the input help for the individual fields, the following input
help is displayed:
 _ For the Airline field, the search help displays the names of the airlines and places the airline
code in the input field for the chosen line. If the airline code is not one of those listed in the
VALUES list of the screen flow logic, the input check triggers an error message in the PAI
event. So the search help overrides the VALUES addition for the input help, but not for the
input checks. This is therefore not an appropriate place to use the VALUE addition.
 _ For the Flight number field, the flow logic displays the selected entries from the database
table SPFLI and places the selected line in the input field.
Input Help in Dialog Modules
You can call dialog modules in the POV event using the event keyword PROCESS ON VALUEREQUEST.
PROCESS ON VALUE-REQUEST.
...
FIELD <f> MODULE <mod>.
...
After the PROCESS ON VALUE-REQUEST statement, you can only use the MODULE
statement together with the FIELD statement. When the user chooses F4 for a field <f>, the
system calls the module <mod> belonging to the FIELD <f> statement. If there is more than one
FIELD statement for the same field <f>, only the first is executed. The module <mod> is defined
in the ABAP program like a normal PAI module. However, the contents of the screen field <f> are
not available, since it is not transported by the FIELD statement during the PROCESS ON
HELP-REQUEST event. You can now program your own value lists in the module. However, this
procedure is only recommended if it really is not possible to use a search help. Defining search
helps is much easier than PROCESS ON VALUE-REQUEST, since the system takes over some
of the standard operations, such as getting field contents from the screen. It also ensures that the
F4 help has a uniform look and feel throughout the system. Furthermore, it means that you do
not have to reassign input help to fields on each screen.
Despite the introduction of search helps (and search help exits), there are still cases in which you
need to use parts of the standard F4 functions directly. In this case, there are some standard
function modules that you can use in the POV event. They support search helps, as well as all
other kinds of input help, and are responsible for data transport between the screen and the input
help. These all have the prefix F4IF_. The most important are:
 _ F4IF_FIELD_VALUE_REQUEST
Calls the input help of the ABAP Dictionary dynamically. You can pass the component
names of a structure or database table of the ABAP Dictionary to the function module in
the import parameters TABNAME and FIELDNAME. The function module starts the
ABAP Dictionary input help [Page 596] for this component. All of the relevant screen
fields are read. If you specify the import parameters DYNPPROG, DYNPNR, and
DYNPROFIELD, the user's selection is returned to the corresponding field on the screen.
If you specify the table parameter RETURN_TAB, the selection is returned into the table
instead.
 _ F4IF_INT_TABLE_VALUE_REQUEST
This function module displays a value list that you created in an ABAP program. The
value list is passed to the function module as the table parameter VALUE_TAB. If you
specify the import parameters DYNPPROG, DYNPNR, and DYNPROFIELD, the user's
selection is returned to the corresponding field on the screen. If you specify the table
parameter RETURN_TAB, the selection is returned into the table instead.
There are also two function modules - DYNP_VALUES_READ and DYNP_VALUES_UPDATE -
that can read the values of screen fields and return values to them during the POV event. For
further information, refer to the relevant function module documentation.
Input help in dialog modules

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_f4_help_module.
TYPES: BEGIN OF values,
carrid TYPE spfli-carrid,
connid TYPE spfli-connid,
END OF values.
DATA: carrier(3) TYPE c,
connection(4) TYPE c.
DATA: progname LIKE sy-repid,
dynnum LIKE sy-dynnr,
dynpro_values TYPE TABLE OF dynpread,
field_value LIKE LINE OF dynpro_values,
values_tab TYPE TABLE OF values.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE INIT OUTPUT
*----------------------------------------------------------------------*
MODULE init OUTPUT.
  progname = sy-repid.
  dynnum = sy-dynnr.
  CLEAR: field_value, dynpro_values.
  field_value-fieldname = 'CARRIER'.
  APPEND field_value TO dynpro_values.
ENDMODULE.                    "INIT OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE VALUE_CARRIER INPUT
*----------------------------------------------------------------------*
MODULE value_carrier INPUT.
  CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST'
    EXPORTING
      tabname     = 'DEMOF4HELP'
      fieldname   = 'CARRIER1'
      dynpprog    = progname
      dynpnr      = dynnum
      dynprofield = 'CARRIER'.
ENDMODULE.                    "VALUE_CARRIER INPUT
*----------------------------------------------------------------------*
*  MODULE VALUE_CONNECTION INPUT
*----------------------------------------------------------------------*
MODULE value_connection INPUT.
  CALL FUNCTION 'DYNP_VALUES_READ'
    EXPORTING
      dyname             = progname
      dynumb             = dynnum
      translate_to_upper = 'X'
    TABLES
      dynpfields         = dynpro_values.
  READ TABLE dynpro_values INDEX 1 INTO field_value.
  SELECT carrid connid
  FROM spfli
  INTO CORRESPONDING FIELDS OF TABLE values_tab
  WHERE carrid = field_value-fieldvalue.
  CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
    EXPORTING
      retfield    = 'CONNID'
      dynpprog    = progname
      dynpnr      = dynnum
      dynprofield = 'CONNECTION'
      value_org   = 'S'
    TABLES
      value_tab   = values_tab.
ENDMODULE.                    "VALUE_CONNECTION INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Cancel
Airline
Flight number
The input fields have been adopted from the program fields CARRIER and
CONNECTION. The pushbutton has the function code CANCEL with function type E.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
PROCESS ON VALUE-REQUEST.
FIELD CARRIER MODULE VALUE_CARRIER.
FIELD CONNECTION MODULE VALUE_CONNECTION.
When the user chooses input help for the individual fields, the following is displayed:
 _ For the Airline field, the POV module VALUE_CARRIER is called. The function module
F4IF_FIELD_VALUE_REQUEST displays the input help for the component CARRIER1
of the structure DEMOF4HELP from the ABAP Dictionary, namely the search help
DEMOF4DE. The user's selection is returned to the screen field CARRIER.
 _ For the Flight number field, the POV module VALUE_CONNECTION is called. The
function module DYNP_VALUE_READ transports the value of the screen field CARRIER
into the program. The program then reads the corresponding values from the database
table SPFLI into the internal table VALUES_TAB using a SELECT statement, and
passes the internal table to F4IF_INT_TABLE_VALUE_REQUEST. This displays the
internal table as input help, and places the user's selection into the screen field
CONNECTION.
Dropdown Boxes
As well as input help, which appears in separate dialog boxes, you can also define input/output
fields as dropdown boxes. A dropdown box offers the user a predefined set of input values from
which to choose. It is not possible to type a entry into a dropdown box, instead, the user must
use one of the values from the list. When the user chooses a value, the PAI event can be
triggered simultaneously. If you use a dropdown box for a field, you cannot at the same time use
the input help button.
List boxes are currently the only type of dropdown box supported. A list box is a value list
containing a single text column of up to 80 characters. Internally, each text field has a key of up
to 40 characters. When the user chooses a line, the contents of the text field are placed in the
input field on the screen, and the contents of the key are placed in the screen field. The contents
and length of the input/output field and the screen field are not necessarily the same.
To make an input/output field into a listbox, you must set the value L or LISTBOX in the
Dropdown attribute in the Screen Painter. The visLg attribute determines the output width of the
list box and the field. You can assign a function code to a listbox field. In this case, the PAI
event is triggered immediately when the user chooses a value from the list, and the function code
is placed in the SY-UCOMM and OK_CODE fields. If you do not assign a function code, the PAI
event must be triggered in the usual way, that is, when the user chooses a pushbutton or an
element from the GUI status.
If you have assigned a list box to an input/output field, you can use the Value list attribute of the
screen element to determine how the value list should be compiled. There are two possibilities:
 _ Value list from input help.
If you do not enter anything in the value list attribute, the text field uses the first column
displayed in the input help [Page 595] assigned to the screen field. The input help can
be defined in the ABAP Dictionary, the screen, or a POV dialog module. The key is
automatically filled.
 _ Value list from the ABAP program.
If you enter A in the value list attribute, you must fill the value list yourself before the
screen is sent (for example, in the PBO event) using the function module
VRM_SET_VALUES. When you do this, you must pass an internal table with the type
VRM_VALUES to the import parameter VALUES of the function module. VRM_VALUES
belongs to the type group VRM. The line type is a structure consisting of the two text
fields KEY (length 40) and TEXT (length 80). In the table, you can combine possible user
entries from the KEY field with any texts from the TEXT component. You specify the
corresponding input/output field in the import parameter ID.
Dropdown list boxes

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_dropdown_listbox.
TYPE-POOLS vrm.
DATA: name TYPE vrm_id,
list TYPE vrm_values,
value LIKE LINE OF list.
DATA: wa_spfli TYPE spfli,
ok_code LIKE sy-ucomm,
save_ok LIKE sy-ucomm.
TABLES demof4help.
name = 'DEMOF4HELP-CONNID'.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE INIT_LISTBOX OUTPUT
*----------------------------------------------------------------------*
MODULE init_listbox OUTPUT.
  CLEAR demof4help-connid.
  SELECT connid cityfrom cityto deptime
  FROM spfli
  INTO CORRESPONDING FIELDS OF wa_spfli
  WHERE carrid = demof4help-carrier2.
    value-key = wa_spfli-connid.
    WRITE wa_spfli-deptime TO value-text
    USING EDIT MASK '_::_'.
    CONCATENATE value-text
    wa_spfli-cityfrom
    wa_spfli-cityto
    INTO value-text SEPARATED BY space.
    APPEND value TO list.
  ENDSELECT.
  CALL FUNCTION 'VRM_SET_VALUES'
    EXPORTING
      id     = name
      values = list.
ENDMODULE.                    "INIT_LISTBOX OUTPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_100
*----------------------------------------------------------------------*
MODULE user_command_100.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'CARRIER'
  AND NOT demof4help-carrier2 IS INITIAL.
    LEAVE TO SCREEN 200.
  ELSE.
    SET SCREEN 100.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_100
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_200
*----------------------------------------------------------------------*
MODULE user_command_200.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'SELECTED'.
    MESSAGE i888(bctrain) WITH text-001 demof4help-carrier2
    demof4help-connid.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_200

The next screen (statically defined) for screen 100 is 200. It has the following layout:
Cancel
Airline
Air Canada
Air France
Alitalia
American Airlines
British Airways
Continental Airways
The component CARRIER2 of the ABAP Dictionary structure DEMOF4HELP is
assigned to the input field. Its Dropdown attribute is set to L, and it has the output
length 15. The Value list attribute is empty, and it has the function code CARRIER.
The pushbutton has the function code CANCEL with function type E.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE USER_COMMAND_100.
The next screen (statically defined) for screen 200 is 100. It has the following layout:
Cancel
Flight number
13:30:00 NEW YORK SAN FRANCISCO
09:00:00 SAN FRANCISCO NEW YORK
12:00:00 FRANKFURT MIAMI
13:30:00 NEW YORK SAN FRANCISCO
09:00:00 SAN FRANCISCO NEW YORK
12:00:00 FRANKFURT MIAMI
The component CONNID of the ABAP Dictionary structure DEMOF4HELP is
assigned to the input field. Its Dropdown attribute is set to L, and it has the output
length 30. The Value list attribute is set to A, and it has the function code
SELECTED. The pushbutton has the function code CANCEL with function type E.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE INIT_LISTBOX.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE USER_COMMAND_200.
The user cannot type any values into the screen fields. When he or she chooses the
input field on screen 100, a value list appears in the list box, compiled from the input
help for the field DEMOF4HELP-CARRIER2. This is the search help H_SCARR,
which is assigned to the check table SCARR. The value list contains the names of
the airlines. When the user chooses an entry, the screen field is filled with the airline
code, and the PAI event is triggered. The module USER_COMMAND_100 checks
the OK_CODE field and calls screen 200.
In the PBO event of screen 200, an internal table LIST is filled with values from the
database table SPFLI. The KEY field is filled with the flight numbers, and other
relevant information is placed in the TEXT field. The table LIST is then passed to the
function module VRM_SET_VALUES. When the user chooses the input field on
screen 200, the TEXT column of the internal table is displayed in the list box. When
the user chooses an entry, the screen field is filled with the corresponding entry from
the KEY field, and the PAI event is triggered. The module USER_COMMAND_200
checks and processes the OK_CODE field.
Modifying Screens Dynamically
The attributes of screen elements are set statically in the Screen Painter when you define them.
However, it is possible to override some of these attributes in ABAP programs with the help of a
special internal table.
The R/3 System contains a function called field selection, which allows you to change the
attributes of screens dynamically.
It is also possible to set the cursor on a screen to a particular position dynamically from your
program.
Setting Attributes Dynamically [Page 612]
The Field Selection Function [Page 620]
Setting the Cursor Position [Page 631]
Setting Attributes Dynamically
Each field on a screen has a set of attributes that are fixed when you define the screen in the
Screen Painter. When an ABAP program is running, a subset of the attributes of each screen
field can be addressed using the system table SCREEN.
The SCREEN Table
SCREEN is like an internal table with a header line. However, you do not have to declare it in
your program. You cannot display it in the Debugger, and cannot use any work area other than
its header line to address it. It has the following structure:
Component Length Type Description Attribute
NAME 30 C Name of the screen field Name
GROUP1 3 C Modification group 1 Group 1
GROUP2 3 C Modification group 2 Group2
GROUP3 3 C Modification group 3 Group3
GROUP4 3 C Modification group 4 Group4
REQUIRED 1 C Field input is mandatory Mandatory field
INPUT 1 C Field is ready for input Input
OUTPUT 1 C Field is for display only Output
INTENSIFIED 1 C Field is highlighted Highlighted
INVISIBLE 1 C Field is suppressed Invisible
LENGTH 1 X Field length VisLg
ACTIVE 1 C Field is active Input/Output/Invisible
DISPLAY_3D 1 C Three-dimensional box Two-dimensional
VALUE_HELP 1 C Input help button display Input help
REQUEST 1 C Input exists -
The final column contains the corresponding attributes of the screen fields in the Screen Painter.
You can modify SCREEN in your ABAP program during the PBO event of a screen. Its contents
override the static attributes of the screen fields for a single screen call. The only statements that
you can use with SCREEN are:
LOOP AT SCREEN.
...
MODIFY SCREEN.
...
ENDLOOP.
You cannot use any further additions in the LOOP AT SCREEN statement.
The component NAME contains the name of the screen field. The components GROUP1 to
GROUP4 can contain any three-character code. These codes allow you to include screen fields
in up to four modification groups. Modification groups are like an extra key field for the table
SCREEN that allow you to change the attributes of all of the elements in a group simultaneously.
You assign elements to modification groups statically in the Screen Painter, although you can
overwrite them dynamically in a program.
The remaining components are for reading and activating or deactivating the display attributes of
screen fields. For all components other than LENGTH, 1 means active and 0 means inactive.
ACTIVE, INPUT, OUTPUT, and INVISIBLE
There are certain hierarchy rules between the components ACTIVE, INPUT, OUTPUT, and
INVISIBLE. They also have different effects depending on their respective static settings.
The ACTIVE component has no equivalent in the element attributes. Instead, it changes the
components INPUT, OUTPUT, and INVISIBLE.
At the beginning of the PBO, ACTIVE is always set to 1, regardless of the static attribute settings.
Setting ACTIVE to 0 automatically sets INPUT = 0, OUTPUT = 0, and INVISIBLE = 1. Any other
changes to the settings of INPUT; OUTPUT, and INVISIBLE for the same table row are ignored.
Conversely, setting INPUT = 0, OUTPUT = 0, and INVISIBLE = 1 sets ACTIVE to 0, and any
further assignment to ACTIVE for the same table row will also be ignored. The setting ACTIVE =
1 has no other effect on the attributes. The only purpose of the ACTIVE component is to allow
you to make a screen field inactive through a single assignment. You should particularly note that
a module call linked to a FIELD statement in the screen flow logic is always executed, even when
SCREEN-ACTIVE = 0 for the field in question. If you want to prevent a module from being
processed for an inactive field, you must specify the FIELD and MODULE statements separately.
There are eight possible combinations of ACTIVE, INPUT, OUTPUT, and INVISIBLE, that have
the following effect on screen fields:
ACTIVE INPUT OUTPUT INVISIBLE Effect
1 1 1 0 Screen field is displayed, even if Invisible is set
statically.
Field contents are displayed.
Ready for input, even if Input is not set statically.
However, not ready for input if the Output only is
set statically.
1 1 0 0 Screen field is displayed, even if Invisible is set
statically, except when Output only is set
statically.
Field contents are not displayed.
Ready for input, even if Input is not set statically.
1 0 1 0 Screen field is displayed, even if Invisible is set
statically.
Field contents are displayed.
Not ready for input, even if Input is set statically.
1 0 0 0 Screen field is displayed, even if Invisible is set
statically, except when Output only is set
statically.
Field contents are not displayed.
Not ready for input, even if Input is set statically.
1 1 1 1 Screen field is displayed, even if Invisible is set
statically, except when Output only is set
statically.
Field contents are not displayed.
Ready for input, even if Input is not set statically.
User input is masked by asterisks (star) .
1 1 0 1 Screen field is displayed, even if Invisible is set
statically, except when Output only is set
statically.
Output is masked by asterisks (star) .
Ready for input, even if Input is not set statically.
User input is masked by asterisks (star) .
1 0 1 1 Screen field inactive.
Screen field is not displayed, regardless of the
static attributes.
0 0 0 1 Screen field inactive.
Screen field is not displayed, regardless of the
static attributes.
If a field is statically-defined as Output only, setting INPUT = 1 has no effect. INPUT is always 0
for these fields. Masking user input by asterisks can be used for entering user passwords.
If a whole line becomes invisible when you make fields invisible, the screen is automatically
made smaller. You can, however, switch off this attribute in the static screen attributes by
selecting Switch off runtime compression.
  REQUIRED
When you set REQUIRED = 1, a field that is ready for input is made mandatory. Users can only
leave the screen when all mandatory fields contain an entry. Exception: Function codes with
type E and modules with the AT EXIT-COMMAND addition.
 DISPLAY_3D
When you set DISPLAY_3D = 0, the three-dimensional frame for input/output fields is removed.
You cannot use DISPLAY_3D = 1 to create a three-dimensional effect for text fields or screen
fields with the Output only attribute.
  VALUE_HELP
Setting VALUE_HELP to 0 or 1 switches the input help button off and on respectively.
 INTENSIFIED
If you set INTENSIFIED = 1, the field contents of input fields are changed from black to red. The
contents of output fields are changed from black to blue.
 LENGTH
You can set the LENGTH component to a value shorter than the statically-defined output length
(vislength) for input/output fields and Output only fields. This allows you to shorten their output
length. You cannot shorten other screen elements, or lengthen any screen elements.
 REQUEST
Setting REQUEST = 1 for a field that is ready for input has the same effect in the PAI event as if
the user had changed the field contents. This means that a conditional module call [Page 572]
using ON REQUEST or ON CHAIN-REQUEST would be executed regardless of whether the
user really changed the field. REQUEST is automatically reset to 0.
Dynamic screen modifications.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_modify_screen.
INCLUDE demo_dynpro_modify_screen_sel.
DATA: field1(10), field2(10), field3(10),
field4(10), field5(10), field6(10).
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE sy-ucomm.
DATA: itab LIKE TABLE OF screen WITH HEADER LINE.
DATA length(2) TYPE c.
field1 = field2 = field3 = '0123456789'.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  CLEAR: itab, itab[].
  SET PF-STATUS 'SCREEN_100'.
  IF save_ok = 'MODIFY'.
    itab-name = text-001.
    APPEND itab.
    LOOP AT SCREEN.
      IF screen-group1 = 'MOD'.
        MOVE-CORRESPONDING screen TO itab.
        APPEND itab.
      ENDIF.
    ENDLOOP.
    PERFORM change_input USING:
    act, inp, out, inv, req, int, d3d, hlp, rqs.
    CALL SELECTION-SCREEN 1100 STARTING AT 45 5.
    PERFORM change_input USING:
    act, inp, out, inv, req, int, d3d, hlp, rqs.
    MESSAGE s159(at) WITH act inp out inv.
    CLEAR itab.
    APPEND itab.
    LOOP AT SCREEN.
      IF screen-group1 = 'MOD'.
        screen-active = act.
        screen-input = inp.
        screen-output = out.
        screen-invisible = inv.
        screen-required = req.
        screen-intensified = int.
        screen-display_3d = d3d.
        screen-value_help = hlp.
        screen-request = rqs.
        screen-length = len.
        MODIFY SCREEN.
      ENDIF.
    ENDLOOP.
    CLEAR itab.
    itab-name = text-002.
    itab-active = act.
    itab-input = inp.
    itab-output = out.
    itab-invisible = inv.
    itab-required = req.
    itab-intensified = int.
    itab-display_3d = d3d.
    itab-value_help = hlp.
    itab-request = rqs.
    itab-length = len.
    APPEND itab.
    CLEAR itab.
    APPEND itab.
  ENDIF.
ENDMODULE.                    "STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'MODIFY'.
      LEAVE TO SCREEN 100.
    WHEN 'LIST'.
      CLEAR itab.
      itab-name = text-003.
      APPEND itab.
      LOOP AT SCREEN.
        IF screen-group1 = 'MOD'.
          MOVE-CORRESPONDING screen TO itab.
          APPEND itab.
        ENDIF.
      ENDLOOP.
      CALL SCREEN 200 STARTING AT 45 5
      ENDING AT 95 22.
  ENDCASE.
ENDMODULE.                    "USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
*  MODULE requested INPUT
*----------------------------------------------------------------------*
MODULE requested INPUT.
  MESSAGE s888(sabapdocu) WITH text-004.
ENDMODULE.                    "USER_COMMAND_0100 INPUT
*----------------------------------------------------------------------*
*  MODULE STATUS_0200 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0200 OUTPUT.
  SET PF-STATUS 'SCREEN_200'.
  SUPPRESS DIALOG.
  LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0.
  FORMAT COLOR COL_HEADING ON.
  WRITE: 10 'ACT', 14 'INP', 18 'OUT', 22 'INV', 26 'REQ',
  30 'INT', 34 'D3D', 38 'HLP', 42 'RQS', 46 'LEN'.
  FORMAT COLOR COL_HEADING OFF.
  ULINE.
  LOOP AT itab.
    IF itab-name = ' '.
      ULINE.
    ELSEIF itab-name = text-001 OR itab-name = text-003.
      FORMAT COLOR COL_NORMAL ON.
    ELSE.
      FORMAT COLOR COL_NORMAL OFF.
    ENDIF.
    len = itab-length.
    length = ' '.
    IF len NE 0.
      length = len.
    ENDIF.
    WRITE: /(8) itab-name,
    11 itab-active,
    15 itab-input,
    19 itab-output,
    23 itab-invisible,
    27 itab-required,
    31 itab-intensified,
    35 itab-display_3d,
    39 itab-value_help,
    43 itab-request,
    47 length.
  ENDLOOP.
ENDMODULE.                    "STATUS_0200 OUTPUT
*&---------------------------------------------------------------------*
*&      Form  CHANGE_INPUT
*&---------------------------------------------------------------------*
FORM change_input CHANGING val.
  IF val = 'X'.
    val = '1'.
  ELSEIF val = ' '.
    val = '0'.
  ELSEIF val = '1'.
    val = 'X'.
  ELSEIF val = '0'.
    val = ' '.
  ENDIF.
ENDFORM.                    "CHANGE_INPUT

The next screen (statically defined) for screen 100 is itself, and it has the following
layout:
Demonstration of dynamic screen modifications
List
Visible input/output field
Visible output field
Visible output only field
Invisible input/output field
Invisible output field
Invisible output only field
Modification Refresh
The input/output fields are assigned to the fields FIELD1 to FIELD6 in the ABAP
program. These fields, along with the text field TEXT in the top line, are assigned to
the modification group MOD. The remaining screen elements are not assigned to a
modification group. The function codes of the pushbuttons are MODIFY, UNDO, and
LIST.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
PROCESS AFTER INPUT.
FIELD FIELD1 MODULE REQUESTED ON REQUEST.
MODULE USER_COMMAND_0100.
MODULE CANCEL AT EXIT-COMMAND.
If you choose Modification, a selection screen appears, on which you can select
which of the components of the SCREEN table should be set to active or inactive. In
the subroutine CHANGE_INPUT, the user input from the checkboxes is converted
into the digits 0 and 1. Selection screen 1100 is defined in the following include
program:

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
* INCLUDE
*DEMO_DYNPRO_MODIFY_SCREEN_SEL **
SELECTION-SCREEN BEGIN OF SCREEN 1100.
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME NO INTERVALS.
  PARAMETERS: act AS CHECKBOX DEFAULT '1',
  inp AS CHECKBOX DEFAULT '1',
  out AS CHECKBOX DEFAULT '1',
  inv AS CHECKBOX DEFAULT '0'.
SELECTION-SCREEN END OF BLOCK b1.
SELECTION-SCREEN BEGIN OF BLOCK b2 WITH FRAME NO INTERVALS.
  PARAMETERS: req AS CHECKBOX DEFAULT '0',
  d3d AS CHECKBOX DEFAULT '1',
  hlp AS CHECKBOX DEFAULT '0',
  int AS CHECKBOX DEFAULT '0'.
SELECTION-SCREEN END OF BLOCK b2.
SELECTION-SCREEN BEGIN OF BLOCK b3 WITH FRAME NO INTERVALS.
  PARAMETERS rqs AS CHECKBOX DEFAULT '0'.
SELECTION-SCREEN END OF BLOCK b3.
SELECTION-SCREEN BEGIN OF BLOCK b4 WITH FRAME NO INTERVALS.
  PARAMETERS len TYPE i DEFAULT 10.
SELECTION-SCREEN END OF BLOCK b4.
SELECTION-SCREEN END OF SCREEN 1100.

When you modify the screen, the current contents of the table SCREEN for the
modification group MOD are placed in the auxiliary table ITAB in the PBO event. This
represents the static settings of the corresponding screen fields. SCREEN is then
modified according to the settings chosen by the user. The user input is also stored
in ITAB.
The screen is displayed, and the fields that belong to the modification group MOD
are displayed according to the new attributes stored in SCREEN. The contents of the
entries for ACTIVE, INPUT, OUTPUT, and INVISIBLE are visible in the status bar.
In the PAI event, the module REQUESTED is called if the user changes the contents
of FIELD1 or sets the REQUEST component of the table SCREEN.
If the user chooses List, the current contents of the table SCREEN are appended to
ITAB in the PAI module USER_COMMAND_0100. Screen 200 is then called as a
modal dialog box. Screen 200 is used to display the list of table ITAB. The contents
of the table SCREEN are displayed before and after modification. This makes it
possible to compare directly the effects of the input on the individual components
and the dependencies between the entries.
The Field Selection Function
This topic describes how a special function Field selection (transaction SFAW and some function
modules) support you in changing screen field attributes dynamically.
Field Selection - Overview
The function Field selection allows you to change the attributes of screen fields dynamically at
runtime. However, you should only use this option if you often need to assign different field
attributes to the same screen for technical reasons. In this case, the same rules apply for all
fields, so any field modification is clear.
The following basic rules apply:
 _ All fields involved in the field selection process are grouped together in field selection
tables and maintained using the Field selection function.
 _ You can maintain fields for an ABAP program or screen group (see below).
 _ On screens belonging to the screen group "blank" ('_'), there is no dynamic field
selection.
 _ Central field selection uses the modification group SCREEN-GROUP1, which therefore
cannot be used for anything else.
 _ If you use fixed special rules in the field selection which are the same as changing the
program, you should make the changes directly in the program, not in the maintenance
transaction.
With field selection, you can activate or deactivate the following attributes at runtime:
 _ Input
_ Output
_ Required
_ Active
_ Highlighted
_ Invisible
You can also determine the conditions and the type of changes involved. During the event
PROCESS BEFORE OUTPUT, you call a function module which checks the conditions and, if
necessary, changes the attributes.
Field selection distinguishes between influencing fields and modified fields. Modified fields must,
of course, be screen fields. All fields should relate to the ABAP Dictionary. You can do this by
creating corresponding interface work areas in the ABAP program using TABLES. At runtime, a
function module analyzes the field contents of the influencing fields and then sets the attributes of
the modified fields accordingly.
 Combining Screens into Screen Groups
Rather than maintaining field selection separately for each screen of a program, you can
combine logically associated screens together in a screen group. This reduces the amount of
maintenance required. To assign a screen to a screen group, enter the group in the field Screen
group on the attributes screen in the Screen Painter.
Calling Field Selection
To call field selection, choose Tools _ ABAP Workbench _ Development _ Other tools _
Field selection. Maintenance is by program and screen group.
Module pool
Screen group
?
Selection
Influencing fields
Modified fields
Assignment of tables to field groups
Display Change
First, you must declare the ABAP Dictionary names of the fields involved. Choose Assign tables
to screen group and enter the tables, for example:
Module pool
Screen group
SAPMTXXX
BILD
Delete entry
Tables allowed for field selection
Table name Text
SPFLI Flight connections
Save your entries and choose Influencing fields to enter the desired influencing fields into the list
and optionally specify a NOT condition, a default value, and a field Cust, for example:
Module pool
Screen group
SAPMTXXX
BILD
Choose
Influencing fld. Text
SPFLI-CARRID Airline
Delete field Copy template
Influencing fields
Op.
NE
Not condition
LH
Def. val. Cust
The NOT condition is to be understood as a preselection. If one of the fields satisfies the NOT
condition, it is not relevant for the following screen modification. Using the NOT condition may
improve performance.
Influencing field: SPFLI-CARRID
NOT condition: NE LH
SPFLI-CARRID is relevant for the field selection only if its contents are not equal to
LH at runtime.
At runtime, the system uses the default value for the field modification if it cannot find the current
value of the influencing field in the list of maintained values. To achieve this, you need to define
an influence for the default value. This option allows you to maintain all the forms of an
influencing field, which have the same influence, with a single entry.
By setting the field Cust accordingly, you can decide whether to allow customers to use the
corresponding field for field selection or not. This field selection option is based on the predefined
SAP field selection and allows customers to set screen attributes to suit their own requirements
within a framework determined by application development. Many application areas have their
own special Customizing transactions for this purpose (these are parameter transactions related
to the Transaction SFAC; refer here to the documentation on the function module
FIELD_SELECTION_CUSTOMIZE)
Then, choose Modified fields to enter all modifiable fields into a list, for example:
Module pool
Screen group
SAPMTXXX
*
Choose
Modified field Text
SPFLI-AIRPFROM Departure airport
Delete field Copy template
Modifiable fields
Field no. Cust
2
You can again set the field Cust accordingly if you want to allow customers to use these
modifiable fields in special Customizing transactions. If Cust is selected, customers can also
modify the field.
Each of these influencing and modifiable fields has an internal number which is unique for each
program. When it is generated, the number is automatically placed in SCREEN-GROUP1 of the
appropriate screens and cannot be changed in Screen Painter. This enables the system to
establish a one-to-one relationship between the field name and SCREEN-GROUP1.
Finally, you create links between influencing and modifiable fields from the two lists: specify
which contents of an influencing field influences the modifiable field in which way.
To link fields, select the fields from both lists with Choose or double-click. If you select an
influencing field, the list of modifiable fields appears and vice versa. From this list, select the
desired link. A list appears in which you can enter the relevant conditions, for example:
Module pool
Screen group
SAPMTXXX
*
Mod. field+ I nfl. field+ Delete entry
Influencing val. Input Output Active Oblig. Intens. Invisible
Influencing field
Modifiable field
SPFLI-CARRID
SPFLI-AIRPFROM
Airline
Departure airport
LH X X
The entry above results in suppressing the display of field SPFLI-AIRPFROM on those screens,
in whose PBO the corresponding field selection function modules are called and if SPFLICARRID
then contains 'LH'.
Combination Rules For Attributes
If several influencing fields influence the same modified field, there must be a combination rule to
determine how these influences are linked. You use the tables to below establish how a single
field attribute is set, if it is activated and/or deactivated by different influences. The screen
processor controls the combination of several attributes.
Input
Field 1
'_' 'X'
Field 2 '' '' '_'
'X' '_' 'X'
Output
Field 1
'_' 'X'
Field 2 '' '' '_'
'X' '_' 'X'
Active
Field 1
'_' 'X'
Field 2 '' '' '_'
'X' '_' 'X'
Mandatory
Field 1
'_' 'X'
Field 2 '' '' 'X'
'X' 'X' 'X'
Highlighted
Field 1
'_' 'X'
Field 2 '' '' 'X'
'X' 'X' 'X'
Invisible
Field 1
'_' 'X'
Field 2 '' '' 'X'
'X' 'X' 'X'
Description of characters:
_ = switched off , X = switched on
If Field 1 makes a screen field invisible (X), Field 2 cannot change this.
Static Attributes in the Screen Painter
In screen modifications, the system takes into account not only the entries you make during field
selection, but also any entries made in Screen Painter. This means that the result of the above
combination is linked to the screen field attributes according to the same linking rules as
individual attributes.
To take advantage of the full dynamic modification range, you should use the following attributes
in the Screen Painter:
Input = 'X'
Output = 'X'
Mandatory = '_'
Invisible = '_'
Highlighted = '_'.
Conversely, you cannot change the values defined on the screen in the following manner:
Input = '_'
Output = '_'
Mandatory = 'X'
Invisible= 'X'
Highlighted = 'X'
Furthermore, the following applies: If you enter the following combination of influences, it is not
really a valid combination, since the combination rules stipulate that the specified display
attributes cannot be changed by another influencing field (or the screen).
Input = 'X'
Output = 'X'
Active = 'X'
Mandatory = '_'
Highlighted = '_'
Invisible = '_'
When you reenter the field selection, influences that have no effect, such as the one above, are
not displayed. However, if you have defined a default value for the influencing field, it can make
sense to display and maintain influences of this kind.
Generating the Field Selection
If the list of modified fields has changed at all, you must generate the field selection. This
produces consecutive numbers for the modified SCREEN-GROUP1 fields in the screens of the
relevant ABAP program.
To generate the field selection, choose Generate from Transaction SFAW.
Function Modules for Field Selection
To activate field selection for a screen in the PROCESS BEFORE OUTPUT event, you can call
one of the function modules FIELD_SELECTION_MODIFY_ALL or
FIELD_SELECTION_MODIFY_SINGLE. Both these function modules determine the contents of
the influencing fields, refer if necessary to the combination rules and execute the screen
modification. FIELD_SELECTION_MODIFY_ALL executes the LOOP AT SCREEN statement
itself. However, with FIELD_SELECTION_MODIFY_SINGLE, you must the LOOP AT SCREEN
yourself and call the function module within the loop. You can thus perform your own additional
screen modifications within the LOOP.
Examples of calling the function modules in the event PBO:
1.
CALL FUNCTION 'FIELD_SELECTION_MODIFY_ALL'
EXPORTING MODULPOOL = MODULPOOL
DYNPROGRUPPE = DYNGRP.
2.
LOOP AT SCREEN.
IF SCREEN_GROUP1 NE SPACE AND
SCREEN-GROUP1 NE '000'.
CALL FUNCTION 'FIELD_SELECTION_MODIFY_SINGLE'
EXPORTING MODULPOOL = MODULPOOL
DYNPROGRUPPE = DYNGRP.
* Special rules
MODIFY SCREEN.
ENDIF.
ENDLOOP.
3.
as 1, but includes your own LOOP AT SCREEN for special rules.
You must decide in each individual case which of the options 2 or 3 produces the best
performance.
Since the Module pool and Screen group parameters determine the field selection, you must
maintain influences for these.
The Module pool parameter defines, in main memory, which loaded module pool you use to
search for the current values of the influencing fields.
When you call the function modules, you may not use the system fields SY-REPID or SYDYNGR
directly as actual parameters. Instead, you must assign them to other fields at an
appropriate point.
 For example:
MODULPOOL = SY-REPID.
DYNGRP = SY-DYNGR
Sometimes, the Module pool values may differ from the current SY_REPID value.
If the Screen group parameter is blank, the system uses the current contents of SY-DYNGR. This
is not possible for the Module pool parameter because the value '_' (blank) prevents any field
modification.
Let us consider an ABAP program in which the second screen contains the following
module call in its PBO event:
PROCESS BEFORE OUTPUT.
...
MODULE MODIFY_SCREEN.
Suppose the module MODIFY_SCREEN contains the following function call:
MODULE MODIFY_SCREEN OUTPUT.
CALL FUNCTION 'FIELD_SELECTION_MODIFY_ALL'
EXPORTING
DYNPROGRUPPE = 'BILD'
MODULPOOL = 'SAPMTXXX'
EXCEPTIONS
OTHERS = 1.
Let us also suppose that the influences for the screen group BILD and the
corresponding ABAP program are maintained as described above.
After calling the transaction, suppose these entries are made:
Airline
Flight number
LH
Display
Change
400
After choosing Change, the following screen appears:
From
Flight data
LUFTHANSA
FRANKFURT
Airline
Flight number
LH
400
To NEW YORK
Departure airport JFK
Duration 08:24:00
Departure time 10:10:00
Arrival time 11:34:00
in KM
Distance 6.162
However, if instead of 'LH' as airline carrier 'AA' is entered, the following screen
appears:
From
Flight data
AMERICAN AIRLINES
NEW YORK
Airline
Flight number
AA
17
To SAN FRANCISCO
Arrival airport SFO
Flight time 06:01:00
Departure time 13:30:00
Arrival time 16:31:00
In MLS
Distance 2.572
Departure airport JFK
When entering 'LH', the field SPFLI-AIRPFROM is invisible. When entering 'AA', it is
visible as Dep. airport.
Linking Fields
Every influencing field influences a field which can be modified regardless of other fields. Linking
influencing fields can be desirable in some cases but then only possible by defining help fields,
which you must set in the application program before calling the function module.
This restriction helps the transparency of the field selection.
 Examples of Links
Suppose we have the following fields:
 _ Influencing fields: F4711, F4712
Field that can be modified: M4711
The following cases can only be implemented using a workaround:
OR Condition and "Ready for Input"
 _ IfF4711 = 'A' OR F4712 = 'B', then
M4711 is ready for input.
Solution:
 _ Define H4711 as an influencing field in SFAW;
define the following condition in SFAW:
if H4711 = 'AB'
then M4711 input on (that is, input = 'X')
In the application program, you must program the following before calling the function module:
IF F4711 = 'A' OR F4712 = 'B'.
H4711 = 'AB'.
ENDIF.
AND Condition and "Mandatory"
 _ IfF4711 = 'A' AND F4712 = 'B',
then M4711 obligatory and only then.
Solution:
 _ Maintenance in the field selection:
If H4711 = 'AB',
then M4711 is a required-entry field
(H4711 = 'AB' only precisely with the above AND condition)
In the application program, you would write the following:
IF F4711 = 'A' AND F4712 = 'B'
H4711 = 'AB'
ELSE.
H4711 =....
ENDIF.
The following cases, on the other hand, can be represented directly:
AND Condition and "Ready for Input"
 _ If F4711 = 'A' AND F4712 = 'B',
then M4711 is ready for input. F4711 <> 'A' OR F4712 <> 'B',
then M4711 is not ready for input.
Solution:
Screen: M4711 ready for
input
Field selection:
Influencing field F4711
Value 'A'
Input ='X'
Value'A1'
Input =' '
Value'AX'
Input =' '
Influencing field F4712
Value 'B'
Input ='X'
Value'B1'
Input =' '
Value'BX'
Input =' '
OR Condition and "Mandatory"
IfF4711 = 'A' OR F4712 = 'B', then
M4711 is a required-entry field.
Solution:
Screen: Mandatory is switched off
Influencing field F4711 Value 'A'
mandatory = 'X'
Influencing field F4712 Value 'B'
mandatory = 'X'
The possibility to define a NOT condition for an influencing field gives further variants of the field
selection definition.
Authorization for Field Selection
The authorization object for Field selection is "central field selection" (S-FIELDSEL). This object
consists of an activity and a program authorization group. The latter is taken from the program
authorizations (ABAP Editor).
Possible activities:
'02' = Change
'03' = Display
'14' = Generate field selection information on screens
'15' = Assign relevant tables to field selection
Changing a field selection modifies the program flow. It is also possible in some applications to
change the screen attributes of a field from within Customizing. This kind of change does not
count as a modification.
Setting the Cursor Position
When a screen is displayed, the system automatically places the cursor in the first field that is
ready for input. However, you can also define on which screen element the cursor should appear
in your program. The screen element does not have to be an input field. Positioning the cursor
can make applications more user-friendly.
You can set the cursor position either statically in the Screen Painter or dynamically in your
ABAP program.
Static Cursor Position
To define the cursor position statically, enter the name of the required screen element in the
Cursor position screen attribute [Page 527] in the Screen Painter.
Dynamic Cursor Position
To set the cursor position dynamically, use the following statement in an ABAP dialog module in
the PBO event:
SET CURSOR FIELD <f> [OFFSET <off>].
<f> can be a literal or a variable containing the name of a screen element. You can use the
OFFSET addition to place the cursor at a particular point within an input/output field.
Setting the cursor position

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_set_cursor.
DATA: field1(14), field2(14), field3(14),
name(10).
SELECTION-SCREEN BEGIN OF BLOCK bloc WITH FRAME.
  PARAMETERS: def RADIOBUTTON GROUP rad,
  txt RADIOBUTTON GROUP rad,
  f1 RADIOBUTTON GROUP rad,
  f2 RADIOBUTTON GROUP rad,
  f3 RADIOBUTTON GROUP rad.
SELECTION-SCREEN END OF BLOCK bloc.
PARAMETERS pos TYPE i.
IF txt = 'X'.
  name = 'TEXT'.
ELSEIF f1 = 'X'.
  name = 'FIELD1'.
ELSEIF f2 = 'X'.
  name = 'FIELD2'.
ELSEIF f3 = 'X'.
  name = 'FIELD3'.
ENDIF.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE CURSOR OUTPUT
*----------------------------------------------------------------------*
MODULE cursor OUTPUT.
  IF def NE 'X'.
    SET CURSOR FIELD name OFFSET pos.
  ENDIF.
  SET PF-STATUS 'SCREEN_100'.
ENDMODULE.                    "CURSOR OUTPUT
*----------------------------------------------------------------------*
*  MODULE BACK INPUT
*----------------------------------------------------------------------*
MODULE back INPUT.
  LEAVE SCREEN.
ENDMODULE.                    "BACK INPUT

At the start of the program, a selection screen appears on which you can select a
cursor position.
Screen 100 is then called. The next screen (statically defined) for screen 100 is
itself, and it has the following layout:
Demonstration for cursor position on the screen
Back
Field 1
Field 2
Field 3
The input/output fields are assigned to the fields FIELD1 to FIELD3 in the ABAP
program. The heading is the text field TEXT, and the pushbutton is the screen
element PUSH.
The static cursor position in the screen attributes is set to PUSH.
T
he screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE CURSOR.
PROCESS AFTER INPUT.
MODULE BACK AT EXIT-COMMAND.
During the PBO event, before screen 100 is displayed, the cursor is set according to
the user's choice on the selection screen. If the user chooses the static default, the
cursor is placed on the pushbutton, otherwise on the header or one of the input
fields. The position POS is only taken into account for the input fields.
Switching on Hold Data Dynamically
In the attributes of a screen [Page 527], you can enable the following standard menu entries by
setting the Hold data attribute:
 _ System _ User profile _ Hold data
Hold data allows users to retain values that they have entered on a screen so that they
appear the next time they start the same transaction. Only values actually entered by
the user are retained. They are placed in the corresponding field as default values each
time the screen is processed, and they overwrite the values transferred from the ABAP
program in the PBO event.
 _ System _ User profile _ Set data
This has the same effect as Hold data. Additionally, when the held data is placed in the
screen fields, these fields are no longer ready for input.
 _ System _ User profile _ Delete data
This deletes the held data, and makes the relevant fields on the screen ready for input
again.
If Hold data is not activated in the screen attributes, the above menu entries have no effect.
In the PBO event of a screen, you can overwrite the Hold data attribute dynamically using the
statement
SET HOLD DATA ON|OFF.
The ON addition activates the attribute, OFF deactivates it.
Example
Hold data

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_set_hold_data.
DATA field(10).
CALL SCREEN 100.
field = 'XXXXXXXXXX'.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE HOLD_DATA OUTPUT
*----------------------------------------------------------------------*
MODULE hold_data OUTPUT.
  SET HOLD DATA ON.
ENDMODULE.                    "HOLD_DATA OUTPUT

The statically-defined next screen for screen 100 is 0, and it contains a single
input/output field called FIELD.
The flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE HOLD_DATA.
PROCESS AFTER INPUT.
In the PBO event, the Hold data attribute is activated dynamically. If the user enters
a value and then chooses System _ User profile _ Hold data or Set data, the same
value is displayed in the field when the screen is next displayed. This value is
displayed each time the screen is called until the user chooses Delete data. This
overwrites any value assigned to the field FIELD in the ABAP program.
Complex Screen Elements
Status Icons
Status icons are display elements that you can use to represent the state of a program
graphically. It is possible to use any SAPgui icon. However, in practice, you should only use the
icons for status display [Ext.] listed in the SAP Style Guide.
You can only create status icons in the graphical Screen Painter. When you create one, you
assign a name and a screen field, called a status field, to it. The visible length of the screen field
determines the amount of space that the icon can take up on the screen. As well as the icon
itself, you can also place text in the field. The actual length (defLg) of the status field must be
long enough for the internal representation of the icon, plus any text and quickinfo text that you
specify. When you create the status icon in the Screen Painter, a placeholder appears on the
screen. You must specify the icon itself and its text and quickinfo text in the PBO event of your
ABAP program.
In order to define the icon in your ABAP program, you must create a field with the same name as
the status field on the screen and the ABAP Dictionary type ICONS-TEXT. You can then fill this
field with the required technical information in the PBO event. When the screen is displayed, the
information is transferred to the status field and the icon appears.
To fill the field in your ABAP program, use the function module ICON_CREATE. It has the
following import parameters:
 _ NAME
The name of the required icon. These are listed in the SAP Style Guide [Ext.], in the
include program <ICON>, or the corresponding input help in the Screen Painter or Menu
Painter.
 _ TEXT
This parameter allows you to enter a text that will appear after the icon on the screen.
 _ INFO
In this parameter, you can specify a quickinfo text, which appears whenever the mouse
pointer is positioned over the icon.
 _ ADD_STDINF
This flag switches the quickinfo display on or off.
The function module converts these parameters into a single string, which is returned in the
export parameter RESULT. When you assign the RESULT parameter to the status field, it
contains all the information required to display the status icon.
Status icons

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_status_icons.
DATA value TYPE i VALUE 1.
DATA: status_icon TYPE icons-text,
      icon_name(20),
      icon_text(10).
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE set_icon OUTPUT
*----------------------------------------------------------------------*
MODULE set_icon OUTPUT.
  SET PF-STATUS 'SCREEN_100'.
  CASE value.
    WHEN 1.
      icon_name = 'ICON_GREEN_LIGHT'.
      icon_text = text-003.
    WHEN 2.
      icon_name = 'ICON_YELLOW_LIGHT'.
      icon_text = text-002.
    WHEN 3.
      icon_name = 'ICON_RED_LIGHT'.
      icon_text = text-001.
  ENDCASE.
  CALL FUNCTION 'ICON_CREATE'
    EXPORTING
      name                  = icon_name
      text                  = icon_text
      info                  = 'Status'
      add_stdinf            = 'X'
    IMPORTING
      RESULT                = status_icon
    EXCEPTIONS
      icon_not_found        = 1
      outputfield_too_short = 2
      OTHERS                = 3.
  CASE sy-subrc.
    WHEN 1.
      MESSAGE e888(bctrain) WITH text-004.
    WHEN 2.
      MESSAGE e888(bctrain) WITH text-005.
    WHEN 3.
      MESSAGE e888(bctrain) WITH text-006.
  ENDCASE.
ENDMODULE.                    "HOLD_DATA OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE CHANGE
*----------------------------------------------------------------------*
MODULE change.
  CASE value.
    WHEN 1.
      value = 2.
    WHEN 2.
      value = 3.
    WHEN 3.
      value = 1.
  ENDCASE.
ENDMODULE.                    "CHANGE

The next screen (statically defined) for screen 100 is itself, and it has the following
layout:
 Continue
The screen contains a status field called STATUS_ICON with a visible length of 12
and defined length 26. The status icon and the space for the text are represented by
placeholders in the Screen Painter.
The screen flow logic is as follows:
PROCESS BEFORE OUTPUT.
MODULE SET_ICON.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE CHANGE.
The dialog module SET_ICON passes various values to the function module
ICON_CREATE, depending on the values of the fields in the program. The status
field STATUS_ICON is filled with the contents of the export parameter RESULT of
the function module. The corresponding icon with its text and quickinfo is then
displayed on the screen. When the user chooses Continue, the contents of the field
VALUE are changed in the PAI, and consequently a new icon is defined in the PBO
event. The following icons and texts are displayed:
Low
Middle
High
The quickinfo text is 'Status' for all of the icons.
Context Menus
The user interface of a screen is defined by a GUI status [Page 548], which you define in the
Menu Painter and assign the type Dialog status. For each dialog status, the system
automatically creates a standard context menu, which the user can display by clicking the righthandmouse button on the screen (or choosing Shift+F10). The standard context menu
contains all of the function keys to which functions are assigned. It therefore makes it easy to
access any function code that is available using the keyboard, since normally only the most
important are assigned to the application toolbar.
However, as well as the standard context menu, you can define context-specific menus for any of
the following screen elements:
 _ Input/output fields
_ Text fields
_ Table controls
_ Group boxes
_ Subscreens
When you select one of these elements using the right-hand mouse button, you can create a
dynamic context menu in the ABAP program. This may contain any functions, and is not
restricted to function keys. You cannot assign context menus to pushbuttons, checkboxes, or
radio buttons. However, you can assign unique function codes to them instead.
Global Class CL_CTMENU
Context menus are objects of the global ABAP Objects [Page 1291] class CL_CTMENU. In the
class library, the class belongs to the Frontend Services component, in which the classes of the
Control Framework are also stored (see Custom Controls [Page 661]). It contains methods that
allow you to define context menus dynamically in a program. As a template, you can create your
own context menus statically in the Menu Painter.
The most important methods of the class CL_CTMENU are:
Method Function
LOAD_GUI_STATUS Assigns a context menu that has already been defined statically
in the Menu Painter to a local context menu in a program
ADD_FUNCTION Assigns a single function to a context menu in a program
ADD_MENU Assigns another local context menu to the current local context
menu in the program
ADD_SUBMENU Assigns another local context menu to the current local context
menu in the program as a cascading menu
ADD_SEPARATOR Adds a separator
HIDE_FUNCTIONS Hides functions
SHOW_FUNCTIONS Shows functions
DISABLE_FUNCTIONS Deactivates functions
ENABLE_FUNCTIONS Activates functions
SET_DEFAULT_FUNCTION Sets a default function, which is highlighted when the menu is
displayed
In the above table, "local context menu in a program" means an object of class CL_CTMENU.
You use CL_CTMENU in different ways depending on the context:
If you use a context menu in a control [Page 661], whether or not you need to create objects of
the class CL_CTMENU depends on the wrapper of the class. (The relevant functions may
already be encapsulated in the control class.) Normally, control users do not have to create their
own context menus. This ensures that no conflicts occur with the event handling of the control.
For further information, refer to the documentation of the individual control classes.
When you define a context menu on a screen (or list [Page 866]), the relevant objects of class
CL_CTMENU are created automatically by the runtime environment, not explicitly in the program.
References to the object are passed as the parameters of special callback routines in the ABAP
program.
Context Menus for Elements on Screens
In order to link a context menu with one of the screen elements above, you only need to enter an
ID <context> in the Context menu field in the element attributes in the Screen Painter. If you do
not define a context menu for a particular screen element, it inherits the context menu from the
hierarchically next-highest element. For example, all screen elements in a group box that do not
have their own context menu would inherit the context menu of the group box. The highest
hierarchy level is the default context menu, containing all of the key settings of the current dialog
status.
If a screen element is linked with a context menu - either its own or one that it has inherited, a
special subroutine
ON_CTMENU_<context>
is called in the ABAP program when the user clicks the right-hand mouse button. The PAI event
is not triggered. You use this subroutine (callback routine) to define the context menu
dynamically. You must program it in the processing logic. If the subroutine does not exist, the
context menu is not displayed.
You can link the same context menu <context> to any number of screen elements. They then all
work with the same subroutine.
Defining Context Menus in the Processing Logic
For each context menu that you want to call for an element on a screen, you need to program a
corresponding callback routine:
FORM ON_CTMENU_<context> USING <l_menu> TYPE REF TO cl_ctmenu.
...
ENDFORM.
Each routine must have a single USING parameter, typed as a reference variable to class
CL_CTMENU. For each context menu assigned to an element on a screen, the runtime
environment automatically creates an object of the class. When the user requests the context
menu by clicking the right-hand mouse button, the system calls the corresponding subroutine and
passes a reference to the corresponding object to the formal parameter.
When the object is passed it is initial - the context menu contains no entries. In the subroutine,
you can work with the methods of the object (as listed above) to construct the context menu
dynamically.
 Using Predefined Context Menus
As well as dialog statuses and dialog box statuses, there is a third kind of GUI status [Page 548]
that you can define in the Menu Painter, namely a context menu. To find out how to create
context menus in the Menu Painter, refer to Creating Context Menus [Ext.].
Predefined context menus allow you to make groups of statically-defined function coded
available context-specifically. The method LOAD_GUI_STATUS allows you to load a context
menu from any ABAP program into a local context menu in a program. As a rule, you use
predefined context menus to reuse the function codes from a dialog status with the same
semantics, but context-specifically. Once you have loaded a predefined context menu into a
local context menu in a program, you can modify it in any way (append other predefined context
menus, add or remove functions, add other context menus).
 Defining New Context Menus
You can create new context-specific menus either by modifying existing ones or by constructing
new menus.
You can add any number of new functions to a context menu. When you add a new function,
you must specify the function text, function code, and function type (for example, E for an
unconditional module call [Page 568]).
However, you can also add any other local context menu from the program. In this case, you
only have to pass a reference to another context menu (see example below). You can create a
collection of context menu objects in your program and use and combine them as necessary.
You can also construct submenus. You can have deep-nested menus by adding submenus to
existing submenus.
 Ergonomic Guidelines
When you create context menus, you should observe the following rules:
_ The functions in a context menu should be a subset of the functions in the program You can
ensure this by using predefined context menus
_ Context menus should not contain more than ten entries at a single level.
_ If you use a context menu for a screen element, it should contain all of the functions possible
for that element, but at least the standard comments such as Select, Copy, Cut, and Paste.
_ The sequence of the functions should be as follows: Object-specific commands, copy
commands, other commands.
_ You should not duplicate functions that can be selected using the left-hand mouse button in a
context menu.
Displaying the Context Menu
Once you have defined the context menu dynamically in the callback routine, the system displays
it on the screen immediately. When the user chooses a function from the menu, the system
triggers the PAI event and places the corresponding function code in SY-UCOMM and the OK
CODE field.
Example
The following example shows some of the technical possibilities for creating context menus, but
does not necessarily observe all of the style guidelines.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_context_menu.
DATA: field1 TYPE i VALUE 10,
      field2 TYPE p DECIMALS 4.
DATA: prog TYPE sy-repid,
      flag(1) TYPE c VALUE 'X'.
DATA: ok_code TYPE sy-ucomm,
      save_ok TYPE sy-ucomm.
prog = sy-repid.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE status_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET TITLEBAR 'TIT100'.
  IF flag = 'X'.
    SET PF-STATUS 'SCREEN_100' EXCLUDING 'REVEAL'.
  ELSEIF flag = ' '.
    SET PF-STATUS 'SCREEN_100' EXCLUDING 'HIDE'.
  ENDIF.
  LOOP AT SCREEN.
    IF screen-group1 = 'MOD'.
      IF flag = 'X'.
        screen-active = '1'.
      ELSEIF flag = ' '.
        screen-active = '0'.
      ENDIF.
      MODIFY SCREEN.
    ELSEIF screen-name = 'TEXT_IN_FRAME'.
      IF flag = 'X'.
        screen-active = '0'.
      ELSEIF flag = ' '.
        screen-active = '1'.
      ENDIF.
      MODIFY SCREEN.
    ENDIF.
  ENDLOOP.
ENDMODULE.                    "status_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE cancel INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "cancel INPUT
*----------------------------------------------------------------------*
*  MODULE user_command_0100
*----------------------------------------------------------------------*
MODULE user_command_0100.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'HIDE'.
      flag = ' '.
    WHEN 'REVEAL'.
      flag = 'X'.
    WHEN 'SQUARE'.
      field2 = field1 ** 2.
    WHEN 'CUBE'.
      field2 = field1 ** 3.
    WHEN 'SQUAREROOT'.
      field2 = field1 ** ( 1 / 2 ).
    WHEN 'CUBICROOT'.
      field2 = field1 ** ( 1 / 3 ).
  ENDCASE.
ENDMODULE.                    "user_command_0100
*********************************************
* Callback-Routines
*********************************************
FORM on_ctmenu_text USING l_menu TYPE REF TO cl_ctmenu.
  CALL METHOD:l_menu->load_gui_status
  EXPORTING program = prog
  status = 'CONTEXT_MENU_1'
  menu = l_menu.
ENDFORM.                    "on_ctmenu_text
*&---------------------------------------------------------------------*
*&      Form  on_ctmenu_frame
*&---------------------------------------------------------------------*
FORM on_ctmenu_frame USING l_menu TYPE REF TO cl_ctmenu.
  CALL METHOD:l_menu->load_gui_status
  EXPORTING program = prog
  status = 'CONTEXT_MENU_2'
  menu = l_menu,
  l_menu->load_gui_status
  EXPORTING program = prog
  status = 'CONTEXT_MENU_1'
  menu = l_menu,
  l_menu->set_default_function
  EXPORTING fcode = 'HIDE'.
ENDFORM.                    "on_ctmenu_frame
*&---------------------------------------------------------------------*
*&      Form  on_ctmenu_reveal
*&---------------------------------------------------------------------*
FORM on_ctmenu_reveal USING l_menu TYPE REF TO cl_ctmenu.
  CALL METHOD:l_menu->load_gui_status
  EXPORTING program = prog
  status = 'CONTEXT_MENU_3'
  menu = l_menu,
  l_menu->load_gui_status
  EXPORTING program = prog
  status = 'CONTEXT_MENU_1'
  menu = l_menu,
  l_menu->set_default_function
  EXPORTING fcode = 'REVEAL'.
ENDFORM.                    "on_ctmenu_reveal
*&---------------------------------------------------------------------*
*&      Form  on_ctmenu_input
*&---------------------------------------------------------------------*
FORM on_ctmenu_input USING l_menu TYPE REF TO cl_ctmenu.
  DATA calculate_menu TYPE REF TO cl_ctmenu.
  CREATE OBJECT calculate_menu.
  CALL METHOD: calculate_menu->add_function
  EXPORTING fcode = 'SQUARE'
  text = text-001,
  calculate_menu->add_function
  EXPORTING fcode = 'CUBE'
  text = text-002,
  calculate_menu->add_function
  EXPORTING fcode = 'SQUAREROOT'
  text = text-003,
  calculate_menu->add_function
  EXPORTING fcode = 'CUBICROOT'
  text = text-004,
  l_menu->add_submenu
  EXPORTING menu = calculate_menu
  text = text-005.
ENDFORM.                    "on_ctmenu_input

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Try the right-hand mouse button (Shift+F10) in various positions
Show event
Event
Input
The relevant extract of the element list is as follows:
Name Type Contents Context menu
TEXT Text Try the... TEXT
FRAME Frame FRAME
TEXT1 Text Input INPUT
FIELD1 I/O INPUT
TEXT2 Text Result
FIELD2 I/O
TEXT_IN_FRAME Text Show event REVEAL
Elements TEXT2 and FIELD2 have no context menus of their own. They inherit the
context menu FRAME from the group box. They are assigned to modification group
MOD.
The flow logic is as follows:
 PROCESS BEFORE OUTPUT.
MODULE status_0100.
PROCESS AFTER INPUT.
MODULE cancel AT EXIT-COMMAND.
MODULE user_command_0100.
The following function codes and GUI status are assigned to this ABAP program:
Function codes BACK CANCEL EXIT HIDE REVEAL
Dialog status
SCREEN_100 X X X X X
Context menus
CONTEXT_MENU_1 X
CONTEXT_MENU_2 X
CONTEXT_MENU_3 X
The table shows the function codes that each GUI status contains.
The dialog status SCREEN_!00 is set statically in the PBO. Function codes HIDE
and REVEAL are displayed or hidden, depending on the contents of the FLAG field.
The context menus for the screen elements are constructed in the callback routines
as follows:
TEXT:
Loads the static context menu CONTEXT_MENU_1 without modification. This
context menu has a single line- Cancel.
FRAME:
Constructed from the static context menus CONTEXT_MENU_2 and
CONTEXT_MENU_1. This has two lines - Hide result and Cancel. The entry for
function code HIDE is highlighted.
REVEAL:
Constructed from the static context menus CONTEXT_MENU_3 and
CONTEXT_MENU_1. This has two lines - Show result and Cancel. The entry for
function code REVEAL is highlighted.
INPUT:
Constructed by including the four-line local context menu CALCULATE_MENU as a
submenu. To do this, the program declares a local reference variable with reference
to class CL_CTMENU, then creates the object and adds the function codes
SQUARE, CUBE, SQUAREROOT, and CUBICROOT. When we include it in the
context menu for INPUT, we must specify a text for the menu entry behind which it
stands.
When a user runs the program and right-clicks the first line, the context menu TEXT
is displayed. When he or she right-clicks the second line, context menu INPUT is
displayed, and for the third line, FRAME is displayed. The fourth line is hidden by
the program. For all other areas of the screen, the system displays the standard
context menu, with all of the static function codes plus F1 and F4.
When the user chooses one of the new dynamic functions, the system calculates
using the number in input field FIELD1 and places the result in FIELD2.
When the user chooses Hide result (HIDE), the program modifies the screen
dynamically. The fourth line becomes visible, and the user can now display the
context menu REVEAL.
Subscreens
Subscreens allow you to embed one screen within another at runtime. The term subscreen
applies both to the screen that you embed, and the area on the main screen in which you place
it. This section is about subscreen areas. The actual screens that you embed are called
subscreen screens. When you use a subscreen, the flow logic of the embedded screen is also
embedded in the flow logic of the main screen. Using subscreens on screens is like using
includes in ABAP programs.
Subscreens allow you to expand the content of a screen dynamically at runtime. For example,
screen exits, which are part of the enhancement concept, use the subscreen technique. Some
complex screen elements, like tabstrip controls [Page 653], also use them.
To use a subscreen, you must:
1. Define the subscreen area(s) on a screen
2. Define suitable subscreen screens
3. Include the subscreen screen in the subscreen area.
Main screen
PBO Screen PAI
Subscreen area
BildschirmPBO
bild PAI
Subscreen screens
BildschirmPBO
Screbeinld PAI
PBO PAI
BildschirmPBOBildschbirilmd
- PAI
PBPOBO Screbeinld PAPI AI
Dynamic inclusion
Defining Subscreen Areas
You define subscreen areas using the Screen Painter in the layout of the screen on which you
want to embed a subscreen. Each subscreen area on a screen has a unique name, and a
position, length, and height. Subscreen areas may not overlap either with each other or with
other screen elements. You can also specify whether a subscreen area can be resized vertically
or horizontally when the user resizes the window. If the area supports resizing, you can specify a
minimum size for it. If the resizing attributes are selected, the PAI event is triggered whenever the
user resizes the main screen.
Defining Subscreen Screens
You can create subscreen screens either in the same program or a different program. To create
a subscreen screen, enter the screen type Subscreen in the screen attributes. The staticallydefinednext screen must be the number of the subscreen itself. Choose a size for the screen, making sure that it fits within the subscreen area into which you want to place it. If the subscreen screen is too big for the subscreen area, only the top left-hand corner of it will be displayed. You create the layout, element list, and flow logic of a subscreen screen in the same way as a normal screen. Subscreens may also include other subscreens. However, the following
restrictions apply:
 _ You should arrange the screen elements so that they are not truncated if a subscreen
area is too small.
 _ If you want to create several subscreen screens in an ABAP program, you should make
sure that the individual screen elements have names unique among the subscreens. If
the subscreen screens belong to the same program as the main screen, you should also
make sure that names are not used twice there. Otherwise, you must separate data
transported from the screen in your ABAP program after each user action (see example).
 _ Subscreens cannot have their own OK_CODE field. Function codes linked to user
actions on subscreens are placed in the OK_CODE field of the main screen. This also
applies to subscreen screens defined in a different program to the main screen.
 _ The flow logic of a subscreen screen may not contain a MODULE ... AT EXITCOMMAND
statement. Type E functions may only be handled in the main screen.
 _ The flow logic of a subscreen screen may not contain any dialog modules containing the
statements SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN, or
LEAVE TO SCREEN. Any of these statements causes a runtime error. You cannot
change the GUI status of a main screen in a subscreen screen.
Including Subscreen Screens
You include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the
main screen.
To include a subscreen screen in the subscreen area of the main screen and call its PBO flow
logic, use the following statement in the PBO event of the main screen:
PROCESS BEFORE OUTPUT.
...
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
...
This statement assigns the subscreen screen with number <dynp> to the subscreen area called
<area>. You can also specify the program in which the subscreen screen is defined (optional). If
you do not specify the program explicitly, the system looks for the subscreen screen in the same
ABAP program as the main program. If it does not find a corresponding subscreen screen, a
runtime error occurs. The PBO flow logic of the subscreen screen is also included at the same
point. This can call PBO modules of the ABAP program in which the subscreen screen is defined.
At the end of the subscreen PBO, the global fields from the program are passed to any
identically-named screen fields in the subscreen screen. The PBO flow logic of the subscreen
screen can itself include further subscreens.
The name <area> of the subscreen area must be entered directly without inverted commas. You
can specify the names <prog> and <dynp> either as literals or variables. If you use variables, you
must declare and fill identically-named variables in the ABAP program. The screen number
<dynp> must be 4 characters long. If you do not assign a subscreen screen to an area, it
remains empty.
To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow
logic of the main screen:
PROCESS AFTER INPUT.
...
CALL SUBSCREEN <area>.
...
This statement includes the PAI flow logic of the subscreen screen included in the subscreen
area <area> in the PBO event. This can call PAI modules of the ABAP program in which the
subscreen screen is defined. Data is transported between identically-named fields in the
subscreen screen and the ABAP program either when the PAI event is triggered, or at the
corresponding FIELD statements in the PAI flow logic of the subscreen screen.
You cannot place the CALL SUBSCREEN statement between CHAIN and ENDCHAIN or LOOP
and ENDLOOP (see table controls [Page 669]). While a subscreen screen is being processed,
the system field SY-DYNNR contains its screen number. Its contents therefore change when the
CALL SUBSCREEN statement occurs and when you return to the main screen.
When you use subscreen screens, remember that the data from their input/output fields is
transported to and from the programs in which they are defined. The function codes of user
actions on the screen, on the other hand, are always placed in the OK_CODE field of the main
screen, and transported into the program in which it is defined. You should therefore name the
function codes of your subscreen screens differently from those of the main screen.
If, for encapsulation reasons, you define subscreen screens in other ABAP programs, you must
ensure that the required global data of your ABAP programs is transported into the program of
the calling screen after you have called their PAI flow logic.
 _ For example, you can define subscreen screens in function groups and pass their global
data to and from function module parameters. You must then call the function modules in
appropriate dialog modules in the main program to transport the data.
 _ You can also export the global data from the main program as a data cluster to ABAP
memory [Page 363] before the PBO of a subscreen screen and import it into a PBO
module of the subscreen.
Example
Subscreens

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_subscreens.
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE sy-ucomm.
DATA: number1(4) TYPE n VALUE '0110',
number2(4) TYPE n VALUE '0130',
field(10), field1(10), field2(10).
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE STATUS_100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_100 OUTPUT.
  SET PF-STATUS 'SCREEN_100'.
ENDMODULE.                    "STATUS_100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE FILL_0110 OUTPUT
*----------------------------------------------------------------------*
MODULE fill_0110 OUTPUT.
  field = 'Eingabe 1'(001).
ENDMODULE.                    "FILL_0110 OUTPUT
*----------------------------------------------------------------------*
*  MODULE FILL_0120 OUTPUT
*----------------------------------------------------------------------*
MODULE fill_0120 OUTPUT.
  field = field1.
ENDMODULE.                    "FILL_0120 OUTPUT
*----------------------------------------------------------------------*
*  MODULE FILL_0130 OUTPUT
*----------------------------------------------------------------------*
MODULE fill_0130 OUTPUT.
  field = 'Eingabe 2'(002).
ENDMODULE.                    "FILL_0130 OUTPUT
*----------------------------------------------------------------------*
*  MODULE FILL_0140 OUTPUT
*----------------------------------------------------------------------*
MODULE fill_0140 OUTPUT.
  field = field2.
ENDMODULE.                    "FILL_0140 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE SAVE_OK INPUT
*----------------------------------------------------------------------*
MODULE save_ok INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
ENDMODULE.                    "SAVE_OK INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0110 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0110 INPUT.
  IF save_ok = 'OK1'.
    number1 = '0120'.
    field1 = field.
    CLEAR field.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_0110 INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_0130 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0130 INPUT.
  IF save_ok = 'OK2'.
    number2 = '0140'.
    field2 = field.
    CLEAR field.
  ENDIF.
ENDMODULE.                    "USER_COMMAND_0130 INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND_100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_100 INPUT.
  CASE save_ok.
    WHEN 'SUB1'.
      number1 = '0110'.
    WHEN 'SUB2'.
      number1 = '0120'.
      CLEAR field1.
    WHEN 'SUB3'.
      number2 = '0130'.
    WHEN 'SUB4'.
      number2 = '0140'.
      CLEAR field2.
  ENDCASE.
ENDMODULE.                    "USER_COMMAND_100 INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Subscreen 1 Subscreen 2 Subscreen 3 Subscreen 4
There are four pushbuttons with the function codes SUB1 to SUB4, and two
subscreen areas AREA1 and AREA2.
In the same ABAP program, there are four subscreen screens 110 to 140. Each of
these fits the subscreen area exactly. The layout is:
Continue
Subscreen 1,2 Subscreen 3,4
Subscreens 110 and 130 Subscreens 120 and 140
The input/output field of all four subscreen screens has the name FIELD. The
function codes of the pushbuttons on the subscreen screens 110 and 130 are OK1
and OK2.
The screen flow logic for screen 100 is as follows:
PROCESS BEFORE OUTPUT.
MODULE STATUS_100.
CALL SUBSCREEN: AREA1 INCLUDING SY-REPID NUMBER1,
AREA2 INCLUDING SY-REPID NUMBER2.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE SAVE_OK.
CALL SUBSCREEN: AREA1,
AREA2.
MODULE USER_COMMAND_100.
The screen flow logic of subscreen screens 110 and 130 is:
PROCESS BEFORE OUTPUT.
MODULE FILL_0110|0130.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_0110|0130.
Die Bildschirmablauflogik der Subscreen-Dynpros 120 und 140 ist:
PROCESS BEFORE OUTPUT.
MODULE FILL_0120|0150.
PROCESS AFTER INPUT.
When you run the program, a screen appears on which subscreens 110 and 130 are
displayed. The pushbuttons on the main screen allow you to choose between two
subscreen screens for each screen area. The pushbuttons on the subscreens allow
you to transfer the data from subscreens 110 and 130 to subscreens 120 and 140.
Since the same field name FIELD is used on all subscreens, the identically-named
ABAP field is transferred more than once in each PBO and PAI event of the main
screen. For this reason, the values have to be stored in the auxiliary fields FIELD1
and FIELD2 in the ABAP program.
The pushbuttons on the subscreen screens have different function codes, and they
are handled normally in an ABAP field. If the function codes had had the same
names, it would again have been necessary to use auxiliary fields.
Tabstrip Controls
A tabstrip control is a screen object consisting of two or more pages. Each tab page consists of a
tab title and a page area. If the area occupied by the tabstrip control is too narrow to display all of
the tab titles, a scrollbar appears, allowing you to reach the titles that are not displayed. There is
also a pushbutton that allows you to display a list of all tab titles.
Tabstrip controls allow you to place a series of screens belonging to an application on a single
screen, and to navigate between them easily. The recommended uses and ergonomic
considerations for tabstrip controls are described in the Tabstrip Control section of the SAP Style
Guide.
The tabstrip control is the set of all the tab pages. Tabstrip controls are therefore subject to the
same restrictions as subscreens. In particular, you cannot change the GUI status when you
switch between pages in the tabstrip control. However, they are fully integrated into the screen
environment, so present no problems with batch input.
To use a tabstrip control on a screen, you must be using a SAPgui with Release 4.0 or higher,
and its operating system must be Motif, Windows 95, MacOS, or Windows NT with version 3.51
or higher.
When you create a tabstrip control, you must:
1. Define the tab area on a screen and the tab titles.
2. Assign a subscreen area to each tab title.
3. Program the screen flow logic.
4. Program the ABAP processing logic.
You must then decide whether you want to page through the tabstrip control at the SAPgui or on
the application server. In the first case, each tab page has its own subscreen. In the second,
there is a single subscreen area that is shared by all tab pages.
Defining the Tabstrip Control Area and Tab Titles
You define both the tabstrip area and the tab titles in the screen layout.
The tabstrip area has a unique name and a position, length, and height. You can also specify
whether the tabstrip area can be resized vertically or horizontally when the user resizes the
window. If the area supports resizing, you can specify a minimum size for it.
When you define a tabstrip area, it already has two tab titles. Tab titles are technically exactly the
same as pushbuttons. To create additional tab titles, simple create pushbuttons in the row
containing the tab titles. Tab titles have the same attributes as pushbuttons, that is, each has a
name, a text, and a function code. You can also use icons and dynamic texts with tab titles.
Assigning a Subscreen Area to a Tab Title
You must assign a subscreen area to each tab title. There are two ways of doing this:
 Paging in the SAPgui
You need to assign a separate subscreen area to each tab title, and define the function codes of
the tab titles with type P (local GUI function). In the screen flow logic, you call all the subscreens
in the PBO event. This means that all of the tab pages reside locally on the SAPgui.
When the user chooses a tab title, paging takes place within the SAPgui. In this respect, the
tabstrip control behaves like a single screen. In particular, the PAI event is not triggered when
the user chooses a tab title, and no data is transported. While this improves the performance of
your tabstrip control, it also has the negative effect that when the user does trigger the PAI event,
all of the input checks [Page 577] for all of the subscreens are performed. This means that when
the user is working on one tab page, the input checks may jump to an unfilled mandatory field on
another page.
Local paging at the SAPgui is therefore most appropriate for screens that display data rather than
for input screens.
 Paging on the Application Server
One subscreen area is shared by all tab titles and called in the PBO event. You define the
function codes of the individual tab titles without a special function type. When the user chooses
a tab page, the PAI event is triggered, and you must include a module in your flow logic that
activates the appropriate tab page and assigns the correct subscreen to the subscreen area.
Since the PAI event is triggered each time the user chooses a tab title, this method is less
economical for the application server, but the input checks [Page 577] that are performed only
affect the current tab page.
Procedure in Either Case
You create the subscreen areas within the tabstrip area. You assign the subscreen areas to one
or more tab titles in the Screen Painter by selecting one or more titles. You can also assign a
subscreen area to a tab title in the tab title attributes by entering the name of the subscreen area
in the Reference field attribute.
The procedure for the alphanumeric Screen Painter is described under Creating Tabstrip
Controls [Ext.].
If you are paging at the SAPgui, create a subscreen area for each tab title. If you are paging at
the application server, select all tab titles and create a single subscreen area. The subscreen
areas may not cover the top line of the tab area. However, within a tab area, more than one
subscreen area can overlap.
Programming the Flow Logic
In the flow logic, all you have to do by hand is include the correct subscreens [Page 647]. The
screen flow and data transport to the ABAP program is the same as for normal subscreens.
There are two ways of programming the screen flow logic, depending on how you have decided
to page through the tabstrip control.
 Paging in the SAPgui
When you page in the SAPgui, you must include a subscreen for each subscreen area:
 PROCESS BEFORE OUTPUT.
...
CALL SUBSCREEN: <area1> INCLUDING [<prog1>] <dynp1>,
<area2> INCLUDING [<prog2>] <dynp2>,
<area3> INCLUDING [<prog3>] <dynp3>,
...
...
PROCESS AFTER INPUT.
...
CALL SUBSCREEN: <area1>,
<area2>,
<area3>,
...
...
 Paging on the Application Server
When you page on the application server, you only have to include a subscreen for the one
subscreen area:
 PROCESS BEFORE OUTPUT.
...
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
...
PROCESS AFTER INPUT.
...
CALL SUBSCREEN <area>.
...
Handling in the ABAP Program
Before you can use a tabstrip control in your ABAP program, you must create a control for each
control in the declaration part of your program using the following statement:
CONTROLS <ctrl> TYPE TABSTRIP.
where <ctrl> is the name of the tabstrip area on a screen in the ABAP program. The control
allows the ABAP program to work with the tabstrip control. The statement declares a structure
with the name <ctrl> . The only component of this structure that you need in your program is
called ACTIVETAB.
 _ Use in the PBO event
Before the screen is displayed, you use the control to set the tab page that is currently
active. To do this, assign the function code of the corresponding tab title to the
component ACTIVETAB:
 <ctrl>-ACTIVETAB = <fcode>.
When you page at the SAPgui, you only need to do this once before the screen is
displayed. This initializes the tabstrip control. The default active tab page is the first
page. After this, the page activated when the user chooses a tab title is set within
SAPgui.
When you page on the application server, you must assign the active page both before
the screen is displayed for the first time, and each time the user pages. At the same
time, you must set the required subscreen screen.
You can suppress a tab page dynamically by setting the ACTIVE field of table SCREEN
[Page 612] to 0 for the corresponding tab title.
 _ Use in the PAI event
In the PAI event, ACTIVETAB contains the function code of the last active tab title on the
screen.
When you page in the SAPgui, this allows you to find out the page that the user can
currently see. When you page at the application server, the active tab page is controlled
by the ABAP program anyway.
The OK_CODE field behaves differently according to the paging method:
 _ Paging in the SAPgui
When you page in the SAPgui, the PAI event is not triggered when the user chooses a
tab title, and the OK_CODE field is not filled. The OK_CODE field is only filled by user
actions in the GUI status or when the user chooses a pushbutton either outside the
tabstrip control or on one of the subscreens.
 _ Paging on the application server
If you are paging at the application server, the PAI event is triggered when the user
chooses a tab title, and the OK_CODE field is filled with the corresponding function code.
To page through the tabstrip control, you must assign the function code to the
ACTIVETAB component of the control:
 This statement overwrites the function code of the last active tab page with that of the
new tab title. At the same time, you must ensure that the correct subscreen is inserted in
the subscreen area.
Otherwise, tabstrip controls are handled like normal subscrens in ABAP programs, that is, the
ABAP program of a subscreen screen must contain the dialog modules called from the flow logic
of the subscreen.
Examples
Tabstrip control, paging at SAPgui

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_tabstrip_local.
CONTROLS mytabstrip TYPE TABSTRIP.
DATA: ok_code TYPE sy-ucomm,
save_ok TYPE sy-ucomm.
mytabstrip-activetab = 'PUSH2'.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'SCREEN_100'.
ENDMODULE.                    "STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND INPUT
*----------------------------------------------------------------------*
MODULE user_command INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'OK'.
    MESSAGE i888(sabapdocu) WITH 'MYTABSTRIP-ACTIVETAB ='
    mytabstrip-activetab.
  ENDIF.
ENDMODULE.                    "USER_COMMAND INPUT

The next screen (statically defined) for screen 100 is itself. It has the following layout:
Tab title 1 Tab title 2 Tab title 3
Continue
The screen contains a tabstrip area called MYTABSTRIP with three tab titles
PUSH1, PUSH2 and PUSH3. The function codes have the same name, and all have
the function type P. One of the subscreen areas SUB1 to SUB3 is assigned to each
tab title. The pushbutton has the name BUTTON and the function code 'OK'.
In the same ABAP program, there are three subscreen screens 110 to 130. Each of
these fits the subscreen area exactly. The layout is:
Subscreen 1,2,3
The screen flow logic for screen 100 is as follows:
 PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
CALL SUBSCREEN: SUB1 INCLUDING SY-REPID '0110',
SUB2 INCLUDING SY-REPID '0120',
SUB3 INCLUDING SY-REPID '0130'.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
CALL SUBSCREEN: SUB1,
SUB2,
SUB3.
MODULE USER_COMMAND.
The screen flow logic of subscreens 110 to 130 does not contain any module calls.
When you run the program, a screen appears on which the second tab page is
active, since the program sets the ACTIVETAB component of the structure
MYTABSTRIP to PUSH2 before the screen is displayed. The user can page through
the tabstrip control without the PAI event being triggered. One of the three
subscreens is included on each tab page.
When the user chooses Continue, the PAI event is triggered, and an information
message displays the function code of the tab title of the page that is currently active.
Tabstrip control with paging on the application server.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_dynpro_tabstrip_local.
CONTROLS mytabstrip TYPE TABSTRIP.
DATA: ok_code TYPE sy-ucomm,
save_ok TYPE sy-ucomm.
DATA number TYPE sy-dynnr.
mytabstrip-activetab = 'PUSH2'.
number = '0120'.
CALL SCREEN 100.
*----------------------------------------------------------------------*
*  MODULE STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'SCREEN_100'.
ENDMODULE.                    "STATUS_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE CANCEL INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "CANCEL INPUT
*----------------------------------------------------------------------*
*  MODULE USER_COMMAND INPUT
*----------------------------------------------------------------------*
MODULE user_command INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  IF save_ok = 'OK'.
    MESSAGE i888(sabapdocu) WITH 'MYTABSTRIP-ACTIVETAB ='
    mytabstrip-activetab.
  ELSE.
    mytabstrip-activetab = save_ok.
    CASE save_ok.
      WHEN 'PUSH1'.
        number = '0110'.
      WHEN 'PUSH2'.
        number = '0120'.
      WHEN 'PUSH3'.
        number = '0130'.
    ENDCASE.
  ENDIF.
ENDMODULE.                    "USER_COMMAND INPUT

The statically-defined next screen for screen 100 is itself, and its layout is the same
as in the above example. However, the function codes of the three tab titles have the
function type <blank> and they all share a single subscreen area SUB.
The same subscreen screens 110 to 130 are defined as in the last example.
The screen flow logic for screen 100 is as follows:
 PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
CALL SUBSCREEN SUB INCLUDING SY-REPID NUMBER.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
CALL SUBSCREEN SUB.
MODULE USER_COMMAND.
In this example, the program includes a subscreen screen in the subscreen area
SUB dynamically during the PBO event.
The screen flow logic of subscreens 110 to 130 does not contain any module calls.
This example has the same function as the previous example, but the paging within
the tabstrip control is implemented on the application server. Each time the user
chooses a tab title, the function code from the OK_CODE field is assigned to the
ACTIVETAB component of structure MYTABSTRIP. At the same time, the variable
NUMBER is filled with the screen number of the subscreen that has to be displayed
in the subscreen area SUB of the tabstrip control.
Custom Controls
A custom control is an area on a screen. You create them in the Screen Painter, and, like all
other screen objects, they have a unique name. You use custom controls to embed controls. A
control is a software component on the presentation server, which can be either an ActiveX
control or a JavaBean, depending on the SAPgui you are using. They allow you to perform
tasks, such as editing texts, locally on the presentation server. The control is driven by the
application logic, which still runs on the application server.
The SAP Control Framework
The controls on the presentation server and the ABAP application programs on the application
server communicate using the SAP Control Framework [Ext.]. This is programmed in ABAP
Objects [Page 1291], and contains a set of global classes that you can find in the Class Browser
under Basis _ Frontend services. These classes encapsulate the communication between the
application server and presentation server, which is implemented using Remote Function Call.
All application controls are encapsulated in a global class. You can find the SAP Basis controls in
the Class Browser under Basis _ Frontend Services or Basis _ Component Integration.
Programs that use controls on a screen work with the methods and events of the global classes
that encapsulates them.
Container Controls
Before you can work with a custom control on a screen, you must assign a SAP Container
Control [Ext.] to it. Container controls are instances of special global classes from the SAP
Control Framework. The global class for custom controls is called
CL_GUI_CUSTOM_CONTAINER. To link a custom control to a container control, pass the
custom control name to the CONTAINER_NAME parameter of the container control constructor
when you instantiate it.
As well as using custom containers, you can link controls to a screen using a SAP Docking
Container. This is encapsulated in the global class CL_GUI_DOCKING_CONTAINER. The SAP
Docking Container does not place the control within a screen. Instead, it attaches it to one of the
four edges. You can nest containers. For example, you can use the SAP Splitter Container
(classes CL_GUI_EASY_SPLITTER_CONTAINER or CL_GUI_SPLITTER_CONTAINER) within
other containers. This allows you to split a custom control or docking control into more than one
area, allowing you to embed more than one control.
Custom Control
Docking Container
Custom Container
Application Control
Application Control
Docking Container
Application Control
Application Controls
You must also create instances for the application controls that you want to place within your
container - for example, a SAP Textedit Control (class CL_GUI_TEXTEDIT) or a SAP Tree
Control (for which there is more than one global class - an example is CL_GUI_SIMPLE_TREE).
When you instantiate the control, you pass a reference to the container in which you want to
place it to the PARENT parameter of its constructor method. The container may be an instance
of the class CL_GUI_CUSTOM_CONTAINER, but can also be an instance of one of the other
SAP Container controls.
Control Methods
For information about control methods and their documentation, refer to the class definitions in
the Class Builder or the SAP Library documentation. To minimize the network load between the
application and presentation servers, method calls are buffered in the automation queue [Ext.]
before being sent to the presentation server at defined synchronization points. One of the
automatic synchronization points is the end of PBO processing. You can force a synchronization
point in your program by calling a method that is not buffered, or by calling the static method
FLUSH.
Control Events
Unlike screens, on which user interaction triggers the PAI event and control returns to the
application server, user interaction on controls is not automatically passed back to the application
server. If you want an event to be passed back to the application server, you must register it in
your program using the special method SET_REGISTERED_EVENTS. For a list of the events
that you can register for each control, refer to its wrapper class in the Class Builder. You can
register two kinds of event handling [Ext.] using SET_REGISTERED_EVENTS:
System Events (Default)
The event is passed to the application server, but does not trigger the PAI. If you have
registered an event handler method in your ABAP program for the event (using the SET
HANDLER statement), this method is executed on the application server.
Within the event handler method, you can use the static method SET_NEW_OK_CODE of the
global class CL_GUI_CFW to set a function code and trigger the PAI event yourself. After the
PAI has been processed, the PBO event of the next screen is triggered.
The advantage of using this technique is that the event handler method is executed automatically
and there are no conflicts with the automatic input checks associated with the screen. The
disadvantage is that the contents of the screen fields are not transported to the program, which
means that obsolete values could appear on the next screen. You can work around this by using
the SET_NEW_OK_CODE method to trigger field transport and the PAI event after the event
handler has finished.
Control
Handler PAI module PBO module
method
SET_NEW_OK_CODE
Handler
method
SET_NEW_OK_CODE
ABAP-Programm
Screen
System event
 Application Events
The event is passed to the application server, and triggers the PAI. The function code that you
pass contains an internal identifier. You do not have to evaluate this in your ABAP program.
Instead, if you want to handle the event, you must include a method call in a PAI dialog module
for the static method DISPATCH of the global class CL_GUI_CFW. If you have defined an event
handler method in your ABAP program for the event (using the SET HANDLER statement), the
DISPATCH method calls it. After the event handler has been processed, control returns to the
PAI event after the DISPATCH statement and PAI processing continues.
The advantage of this is that you can specify yourself the point at which the event is handled, and
the contents of the screen fields are transported to the application server beforehand. The
disadvantage is that this kind of event handling can lead to conflicts with the automatic input
checks on the screen, causing events to be lost.
Control
PAI module PBO module
DISPATCH
PAI module
DISPATCH
Handler
method
Handler
method
ABAP program
Screen
Application event
Further Information
For further information about controls, and in particular, help on troubleshooting and optimizing
synchronization, refer to BC Controls Tutorial [Ext.] and BC SAP Control Framework [Ext.].
Example
The following example shows the difference between system and application events.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
REPORT demo_custom_control .
* Declarations
*******************************************
CLASS event_handler DEFINITION.
  PUBLIC SECTION.
    METHODS: handle_f1 FOR EVENT f1 OF cl_gui_textedit
    IMPORTING sender,
    handle_f4 FOR EVENT f4 OF cl_gui_textedit
    IMPORTING sender.
ENDCLASS.                    "event_handler DEFINITION
DATA: ok_code LIKE sy-ucomm,
save_ok LIKE sy-ucomm.
DATA: init,
container TYPE REF TO cl_gui_custom_container,
editor TYPE REF TO cl_gui_textedit.
DATA: event_tab TYPE cntl_simple_events,
event TYPE cntl_simple_event.
DATA: line(256),
text_tab LIKE STANDARD TABLE OF line,
field LIKE line.
DATA handle TYPE REF TO event_handler.
* Reporting Events
*****************************************
START-OF-SELECTION.
  line = 'First line in TextEditControl'.
  APPEND line TO text_tab.
  line = '--------------------------------------------------'.
  APPEND line TO text_tab.
  line = '...'.
  APPEND line TO text_tab.
  CALL SCREEN 100.
* Dialog Modules
*******************************************
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'SCREEN_100'.
  IF init IS INITIAL.
    init = 'X'.
    CREATE OBJECT:
    container EXPORTING container_name = 'TEXTEDIT',
    editor EXPORTING parent = container,
    handle.
    event-eventid = cl_gui_textedit=>event_f1.
    event-appl_event = ' '. "system event
    APPEND event TO event_tab.
    event-eventid = cl_gui_textedit=>event_f4.
    event-appl_event = 'X'. "application
    event
    append event to event_tab.
    CALL METHOD: editor->set_registered_events
    EXPORTING events = event_tab.
    SET HANDLER handle->handle_f1
    handle->handle_f4 FOR editor.
  ENDIF.
  CALL METHOD editor->set_text_as_stream
    EXPORTING
      text = text_tab.
ENDMODULE.                    "status_0100 OUTPUT
*----------------------------------------------------------------------*
*  MODULE cancel INPUT
*----------------------------------------------------------------------*
MODULE cancel INPUT.
  LEAVE PROGRAM.
ENDMODULE.                    "cancel INPUT
*----------------------------------------------------------------------*
*  MODULE user_command_0100 INPUT
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.
  save_ok = ok_code.
  CLEAR ok_code.
  CASE save_ok.
    WHEN 'INSERT'.
      CALL METHOD editor->get_text_as_stream
        IMPORTING
          text = text_tab.
    WHEN 'F1'.
      MESSAGE i888(sabapdocu) WITH text-001.
    WHEN OTHERS.
      MESSAGE i888(sabapdocu) WITH text-002.
      CALL METHOD cl_gui_cfw=>dispatch.
  ENDCASE.
  SET SCREEN 100.
ENDMODULE.                    "user_command_0100 INPUT
* Class Implementations
************************************
CLASS event_handler IMPLEMENTATION.
  METHOD handle_f1.
    DATA row TYPE i.
    MESSAGE i888(sabapdocu) WITH text-003.
    CALL METHOD sender->get_selection_pos
      IMPORTING
        from_line = row.
    CALL METHOD sender->get_line_text
      EXPORTING
        line_number = row
      IMPORTING
        text        = field.
    CALL METHOD cl_gui_cfw=>set_new_ok_code
      EXPORTING
        new_code = 'F1'.
    CALL METHOD cl_gui_cfw=>flush.
  ENDMETHOD.                                                "handle_f1
  METHOD handle_f4.
    DATA row TYPE i.
    MESSAGE i888(sabapdocu) WITH text-004.
    CALL METHOD sender->get_selection_pos
      IMPORTING
        from_line = row.
    CALL METHOD sender->get_line_text
      EXPORTING
        line_number = row
      IMPORTING
        text        = field.
    CALL METHOD cl_gui_cfw=>flush.
  ENDMETHOD.                                                "handle_f4
ENDCLASS.                    "event_handler IMPLEMENTATION

The layout of screen 100 is:
Contents of line on F1 or F4
TextEditControl:
F1: System event, F4: Application event
The screen contains an output field FIELD and a custom control called TEXTEDIT.
It has the following flow logic:
 PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
PROCESS AFTER INPUT.
MODULE CANCEL AT EXIT-COMMAND.
MODULE USER_COMMAND_0100.
The GUI status SCREEN_100 has the functions BACK, EXIT, and CANCEL (all with
type E) and the function INSERT (normal function).
There is a local class EVENT_HANDLER defined in the program. It contains event
handler methods for the F1 and F4 events of global class CL_GUI_TEXTEDIT.
When you run the program, the classes CL_GUI_CUSTOM_CONTROL,
CL_GUI_TEXTEDIT, and EVENT_HANDLER are instantiated in the PBO of screen
100.
The container control is linked to the custom control on the screen, and the instance
of the SAP Textedit is linked to the container. The F1 and F4 events of the SAP
Textedit are registered using the SET_REGISTERED_EVENTS method to ensure
that they are passed to the application server when they occur. F1 is defined as a
system event, F4 as an application event. The event handler methods of the
HANDLE instance of the class EVENT_HANDLER are registered as handlers for the
events.
Before screen 100 is displayed, the program fills the SAP Textedit Control with the
contents of table TEXT_TAB. The user can edit the text while the screen is
displayed. If the user chooses INSERT, the PAI event is triggered and the current
text from the SAP Textedit is copied into table TEXT_TAB.
If the user chooses F1 on the control, the HANDLE_F1 method is executed. This
assigns the contents of the line to the field FIELD: The method
SET_NEW_OK_CODE triggers the PAI event. It is this that ensures that the PBO is
processed, and the contents of FIELD are sent to the screen.
If the user chooses F4 on the control, the PAI event is triggered. The DISPATCH
method is called, and this triggers the method HANDLE_F4. This assigns the
contents of the line to the field FIELD: Since the PAI processing continues after the
event, the PBO event follows, and the field contents are transferred to the screen.
The contents of the control are not passed to the internal table TEXT_TAB either
after F1 or after F4. The contents of the control are therefore overwritten in the PBO
event with the previous contents of TEXT_TAB.
Table Controls
ABAP offers two mechanisms for displaying and using table data in a screen. These mechanisms
are table controls and step loops. Table controls and step loops are types of screen tables you
can add to a screen in the Screen Painter.
Using the LOOP Statement
The LOOP...ENDLOOP screen command lets you perform looping operations in the flow logic.
You can use this statement to loop through both table controls and step loops. Between a LOOP
and its ENDLOOP, you can use the FIELD, MODULE, SELECT, VALUES and CHAIN screen
keywords. Most often, you use the MODULE statement to call an ABAP module.
You must code a LOOP statement in both the PBO and PAI events for each table in your screen.
This is because the LOOP statement causes the screen fields to be copied back and forth
between the ABAP program and the screen field. For this reason, at least an empty
LOOP...ENDLOOP must be there.
There are two important forms of the LOOP statement:
 _ LOOP.
This statement loops through screen table rows, transferring the data in each block to
and from the corresponding ABAP fields in your program. The screen table fields may be
declared in ABAP as anything (database table, structure or individual fields) except as
internal table fields.
With step loops, if you are implementing your own scrolling (for example, with F21-F24)
you must use this statement.
 _ LOOP AT <internal table>.
This statement loops through an internal table and the screen table rows in parallel. The
screen table fields often are, but need not be, declared as internal table fields.
With this LOOP, step loop displays appears with scroll bars. This scrolling is handled
automatically by the system.
For more details on the different LOOP statements, see:
Looping Directly Through a Screen Table
Looping Through an Internal Table
Looping Through an Internal Table
If you write the statement
LOOP AT <internal table>.
loops through an internal table and a screen table in parallel. In particular, LOOP AT loops
through the portion of the internal table that is currently visible in the screen. You can use this
form of the LOOP statement for both table controls and step loops.
The complete syntax for this form of the LOOP statement is:
LOOP AT <internal table> CURSOR <scroll-var>
WITH CONTROL <table-control>
FROM <line1> TO <line2>.
...<actions>...
ENDLOOP.
This form of LOOP loops through the internal table, performing <actions> for each row. For each
internal table row, the system transfers the relevant program fields to or from the corresponding
screen table row.
When using step loops, omit the CURSOR parameter in the PAI event. The FROM and TO
parameters are only possible with step loops. (For further information, refer to Using Step Loops
[Page 679].) The WITH CONTROL parameter is only for use with table controls.
For further information, refer to the following sections:
How the System Transfers Data Values
Scrolling and the Scroll Variables
Example Transaction: Table Controls
Transaction TZ60 is an example of programming with table controls. It displays flight information
on two screens. On the first, the user specifies a flight connection and requests the detailed
information. On the second (screen 200), the transaction displays all flights scheduled for the
connection:
There are two important things to notice in this program:
 _ how table data is fetched and passed around
The fields in the table control are declared as database fields (table SFLIGHTS) in the
ABAP program. To store several SFLIGHTS rows at a time, the program uses the
internal table INT__FLIGHTS._
1. During PAI for screen 100, the program selects all flights for the given connection and stores
them in internal table INT___FLIGHTS.
2. AT PBO for screen 200, the LOOP statement loops through INT__FLIGHTS,_ calling the
module DISPLAY__FLIGHTS for each row. DISPLAY_FLIGHTS transfers an INT__FLIGHTS
row to the SFLIGHTS work area. The SFLIGHTS fields match the screen table names, so at
the end of each loop pass, the system transfers the ABAP values to the screen table fields.
_ use of table control fields to control scrolling
Table controls contain information for managing scrolling. This includes fields telling how
many table rows are filled and which table row should be first in the screen display into
the table. For both step loops and table controls, the system manages scrolling with the
scroll bars automatically. This includes scrolling the actual screen display, as well as
resetting scrolling variables. However, the example program offers scrolling with the F21-
F24 keys. In this case, the program must implement these functions explicitly.
1. During PAI for screen 100, the program initializes the "first-table-row" variable (field
TOP___LINE) to 1.
2. At PAI for screen 200, the program resets scrolling variables, especially the TOP_LINE field,
if the user has scrolled with the F21-F24 function keys.
 Screen Flow Logic
The screen flow logic (PAI only) for screen 200 in transaction TZ60 looks as follows.
*---------------------------------------------------------------*
* Screen 200: Flow Logic *
*&--------------------------------------------------------------*
PROCESS BEFORE OUTPUT.
MODULE STATUS_0200.
LOOP AT INT_FLIGHTS WITH CONTROL FLIGHTS
CURSOR FLIGHTS-CURRENT_LINE.
MODULE DISPLAY_FLIGHTS.
ENDLOOP.
**
PROCESS AFTER INPUT.
LOOP AT INT_FLIGHTS.
MODULE SET_LINE_COUNT.
ENDLOOP.
MODULE USER_COMMAND_0200.
 ABAP Code
The following section of the TOP-module code shows the definitions relevant to the following
code.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
*----------------------------------------------------------------*
* INCLUDE MTD40TOP *
*----------------------------------------------------------------*
PROGRAM sapmtz60 MESSAGE-ID a&.
TABLES: sflight.
*<....Other declarations....>
DATA int_flights LIKE sflight OCCURS 1 WITH HEADER LINE.
DATA: line_count TYPE i.
CONTROLS: flights TYPE TABLEVIEW USING SCREEN 200.
*&---------------------------------------------------------------*
*& Module DISPLAY_FLIGHTS OUTPUT
*&---------------------------------------------------------------*
MODULE display_flights OUTPUT.
  sflight-fldate = int_flights-fldate.
  sflight-price = int_flights-price.
  sflight-currency = int_flights-currency.
  sflight-planetype = int_flights-planetype.
  sflight-seatsmax = int_flights-seatsmax.
  sflight-seatsocc = int_flights-seatsocc.
ENDMODULE.                    "DISPLAY_FLIGHTS OUTPUT

At PAI, the program must loop again, to transfer screen table fields back to the program. During
this looping, the program can use SY_LOOPC to find out how many rows were transferred.
SY_LOOPC is a system variable telling the total number of rows currently showing in the display.
*&---------------------------------------------------------------*
*& Module SET_LINE_COUNT INPUT
*&---------------------------------------------------------------*
MODULE SET_LINE_COUNT INPUT.
LINE-COUNT = SY-LOOPC.
ENDMODULE
Transaction TZ60 lets the user press function keys (F21-F24) to scroll the display. The system
handles scrolling with the scroll bars automatically, but not scrolling with function keys. So PAI for
screen 200 must implement function-key scrolling explicitly:
MODULE USER_COMMAND_0200 INPUT.
CASE OK_CODE.
WHEN 'CANC'...
WHEN 'EXIT'...
WHEN 'BACK'...
WHEN 'NEW'...
WHEN 'P--'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P--'.
WHEN 'P-'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P-'.
WHEN 'P+'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P+'.
WHEN 'P++'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P++'.
ENDCASE.
ENDMODULE.
The PAGING routine causes the system to scroll the display by re-setting the table control field
TOP__LINE to a new value. The TOP__LINE field tells the LOOP statement where to start looping
at PBO.

Error rendering macro 'code': Invalid value specified for parameter 'com.atlassian.confluence.ext.code.render.InvalidValueException'
*&---------------------------------------------------------------*
*& Form PAGING
*&---------------------------------------------------------------*
FORM paging USING code.
  DATA: i TYPE i.
  j type i.
  CASE code.
    WHEN 'P--'. flights-top_line = 1.
    WHEN 'P-'.
      flights-top_line = flights-top_line - line_count.
      IF flights-top_line LE 0.
        flights-top_line = 1.
      ENDIF.
    WHEN 'P+'.
      i = flights-top_line + line_count.
      j = flights-lines - line_count + 1.
      IF j LE 0.
        j = 1.
      ENDIF.
      IF i LE j.
        flights-top_line = i.
      ELSE.
        flights-top_line = j.
      ENDIF.
    WHEN 'P++'.
      flights-top_line = flights-lines - line_count + 1.
      IF flights-top_line LE 0.
        flights-top_line = 1.
      ENDIF.
  ENDCASE.
ENDFORM.                    "PAGING

Looping Directly Through a Screen Table
Use the simple form of the LOOP statement
LOOP.
...<actions>...
ENDLOOP.
to loop through the currently displayed rows of a screen table. If you are using a table control,
include the additional WITH CONTROL parameter:
LOOP WITH CONTROL <table control>.
...<actions>...
ENDLOOP.
This simple LOOP is the most general form of the LOOP statement. If you use this LOOP, you
can declare the screen table fields as any type (internal table, database table, structure or
individual fields). The simple LOOP copies the screen table fields back and forth to the relevant
ABAP fields. If you want to manipulate the screen values in a different structure, you must
explicitly move them to where you want them.
Each pass through the loop places the next table row in the ABAP fields, and executes the LOOP
<actions> (usually ABAP module calls) for it. In a PBO event, the LOOP statement causes loop
fields in the program to be copied row by row to the screen. In a PAI event, the fields are copied
row by row to the relevant program fields.
In an ABAP module, use the system variable SY-STEPL to find out the index of the screen table
row that is currently being processed. The system sets this variable each time through the loop.
SY-STEPL always has values from 1 to the number of rows currently displayed. This is useful
when you are transferring field values back and forth between a screen table and an internal
table. You can declare a table-offset variable in your program (often called BASE, and usually
initialized with SY-LOOPC) and use it with SY-STEPL to get the internal table row that
corresponds to the current screen table row.
(In the example below, the screen fields are declared as an internal table. The program reads or
modifies the internal table to get table fields passed back and forth to the screen.)
**SCREEN FLOW LOGIC**
PROCESS BEFORE OUTPUT.
LOOP.
MODULE READ_INTTAB.
ENDLOOP.
PROCESS AFTER INPUT.
LOOP.
MODULE MODIFY_INTTAB.
ENDLOOP.
**ABAP MODULES**
MODULE READ_INTTAB.
IND = BASE + SY-STEPL - 1.
READ TABLE INTAB INDEX IND.
ENDMODULE.
MODULE MODIFY_INTTAB.
IND = BASE + SY-STEPL - 1.
MODIFY INTTAB INDEX IND.
ENDMODULE.
Remember that the system variable SY-STEPL is only meaningful within
LOOP...ENDLOOP processing. Outside the loop, it has no valid value.
How the System Transfers Data Values
With the LOOP AT <internal table> statement, the screen table need not be declared as the
internal table. Screen tables can also be database tables, structures or other program fields. If
you don't define the screen table as an internal table, you must make sure that the correct fields
are moved to and from the internal table header as needed during looping.
Note also that the fields you use in the screen table may be only a subset of the corresponding
dictionary or internal table fields. The system transfers fields as needed in the screen table.
Processing (in detail) is as follows:
  _ PBO processing
1. A row of the internal table is placed in the header area.
2. All loop statements are executed for that row.
Loop statements are most often calls to ABAP modules. Where necessary, these
modules should move the internal table fields to the relevant program fields
(dictionary table or other fields).
Example transaction TZ60 does this in the DISPLAY_FLIGHTS routine:
MODULE DISPLAY_FLIGHTS OUTPUT.
SFLIGHT-FLDATE = INT_FLIGHTS-FLDATE.
SFLIGHT-PRICE = INT_FLIGHTS-PRICE.
SFLIGHT-CURRENCY = INT_FLIGHTS-CURRENCY.
SFLIGHT-PLANETYPE = INT_FLIGHTS-PLANETYPE.
SFLIGHT-SEATSMAX = INT_FLIGHTS-SEATSMAX.
SFLIGHT-SEATSOCC = INT_FLIGHTS-SEATSOCC.
ENDMODULE.
3. The system transfers values from the program fields to the screen fields with the same
names.
 _ PAI processing
4. A row of the internal table is placed to the internal table header area.
5. All screen table fields are transferred to the ABAP program fields with the same names.
6. All loop <actions> are executed for the current internal table row.
Again, <actions> is usually a call to an ABAP module. Where necessary, this module
should first move the program field values to the header area for the internal table.
This step overwrites data values from the internal table with those from the screen.
Step 1 is necessary for cases where the screen table fields are only a subset of the
fields defined for the internal table. If you want to update the internal table with new
screen values, you must have the original table row as a basis in the header area.
Remember: If you want to update the internal table with the contents of the header
area, use the MODIFY statement in the ABAP module. The system does not
automatically do it for you.
Note that there is a screen language MODIFY statement and an ABAP MODIFY
statement. Do not use the screen language MODIFY to update internal tables.
Using Step Loops
If you have a step loop in your screen, you can place the cursor on a particular element in the
step loop block. Use the LINE parameter, entering the line of the loop block where you want to
place the cursor:
SET CURSOR FIELD <fieldname> LINE <line>.
If you want, you can use the OFFSET and LINE parameters together.
A step loop is a repeated series of field-blocks in a screen. Each block can contain one or more
fields, and can extend over more than one line on the screen.
Step loops as structures in a screen do not have individual names. The screen can contain more
than one step loop, but if so, you must program the LOOP...ENDLOOPs in the flow logic
accordingly. The ordering of the LOOP...ENDLOOPs must exactly parallel the order of the step
loops in the screen. The ordering tells the system which loop processing to apply to which loop.
Step loops in a screen are ordered primarily by screen row, and secondarily by screen column.
Transaction TZ61 (development class SDWA) implements a step loop version of the table you
saw in transaction TZ60. Screen 200 for TZ61, shows the following step loop:


  • No labels