In an SAP GUI environment, there are typically three types of screens: the selec-

tion screen, the list screen, and the general screen. In ABAP, a screen is also
known as a dynamic program (dynpro). A dynpro is a component of a program and
can be defined for three types of ABAP programs: executable programs, module
pool programs, and function groups. A program can have multiple dynpros.

A dynpro consists of a screen, dynpro fields, and dynpro flow logic. General dyn-
pros are created with the Screen Painter tool, and special dynpros (selection
screens, list screens) are created implicitly using specific keywords. For example,
SELECT-OPTIONS and PARAMETERS define selection screens, and WRITE defines a list
screen.

Dynpro flow logic contains processing blocks for events that are triggered before
a screen is displayed to the user and after user action on the displayed screen.
Using these processing blocks, we can control the behavior of a dynpro and react
to user actions. You’ll learn about various processing blocks in Chapter 7. Dyn-
pros, together with the new web-oriented features (such as ABAP Web Dynpro)
of SAP NetWeaver AS ABAP, form the basis of user dialogs in an ABAP system.

In this chapter, we’ll discuss the rudimentary concepts of selection screens to get
you started with basic report development, and you’ll use all the concepts dis-
cussed so far in this book to develop a report program (see Section 1.1). This will
allow you to understand the practical application of these concepts. We’ll defer
an in-depth discussion of selection screens to Chapter 14, and we’ll discuss the
other two screens in Chapter 1 (general screens) and Chapter 13 (list screens).

11
1 User Interaction

In Section 1. , we’ll discuss messages so that you cannot only take user inputs for
your program through the selection screen but also validate the input and show a
message to the user accordingly.

1.1 Selection Screen Overview

Selection screens are special dynpros that can be defined in certain program
types—for example, executable programs, function groups, and module pools.
Selection screens are defined in the global declaration area of an ABAP program
with the statements SELECT-OPTIONS, SELECTION-SCREEN, and PARAMETERS, with-
out using the Screen Painter tool. The screens of the selection screens can contain
a subset of the screen elements of general dynpros.

Selection screens are typically used in report programs, in which we first present
the user with a screen to provide the selection criteria and then based on user
input pull the required data from the database to be presented as the report out-
put.

For example, if we want to develop a report to show a flight’s status, we first need
to take the input (selection criteria) from the user to determine the flight number.
The user typically provides this input on a selection screen. After processing, we
show the result on a different screen (either list dynpro or general dynpro).

Selection screens essentially have two tasks:

They enable users to provide selection criteria for a report program.

They provide an interface for data transfer between two executable programs
when a program is called internally using the SUBMIT statement.

Each screen is assigned a four-digit number. A program can have a standard selec-
tion screen and a user-defined selection screen. Screen number 1000 is assigned to
the standard selection screen by default. The standard selection screen is created
automatically when you use the PARAMETERS or SELECT-OPTIONS keyword in the
global declaration area of the program. Other user-defined selection screens can
be created for the program using the SELECTION-SCREEN BEGIN OF SCREEN keyword
with each user-defined screen assigned a unique screen number.

The SELECTION-SCREEN statement can also be used to define different blocks with
frames to better organize the selection screen fields (see Figure 1.1). All screens

1
 Selection Screen Overview 1.1

(such as general screens, selections screens, and list screens) share the same
namespace in the program, so you can’t assign the same screen number to differ-
ent types of screens in the same program.

Figure 1.1 Selection Screen Fields Organized with Blocked Frames

When you use the PARAMETERS or SELECT-OPTIONS keyword in the program and
activate it, the system automatically creates the screen with all the screen ele-
ments and dynpro flow logic. If the SELECTION-SCREEN keyword is not used to
define a user-defined screen, then the program automatically creates a standard
selection screen with dynpro number 1000 and with all the PARAMETERS and
SELECT-OPTIONS fields belonging to this standard screen.

We can define various screen elements on the selection screen, such as input
fields, checkboxes, radio buttons, list boxes, and push buttons. All the screen ele-
ments are defined in the program using the PARAMETERS keyword. The SELECT-
OPTIONS keyword defines a range field on the selection screen, which supports
more complex selection criteria.

In the following subsections, we’ll discuss the PARAMETERS, SELECT-OPTIONS, and

SELECTION-SCREEN keywords in more detail.

13
1 User Interaction

1.1.1 PARAMETERS
Parameters are components of a selection screen that are assigned a global ele-
mentary data object in the ABAP program and an input field on the selection
screen. In other words, the PARAMETERS keyword performs two tasks:

Defines a data object in the program

Defines a screen element (such as an input field or checkbox) on the selection

screen

The system automatically links a program data object with the screen field to
facilitate automatic data transfer between the screen and the program. Thereby
the user inputs on the screen are automatically transferred to the ABAP program
and stored in the corresponding data object, which can then be accessed by ABAP
statements.

The syntax for using the PARAMETERS keyword is somewhat similar to that of the
DATA keyword, with its own set of additions. The PARAMETERS field is typed by
referring to a data type from which it derives its technical attributes. Listing 1.1
shows the syntax to use the PARAMETERS statement.

PARAMETERS {para TYPE data_type}

[type_options]
[screen_options]
[value_options]

Listing 1.1 Parameters Keyword Syntax

Listing 1. shows an example of the PARAMETERS keyword in action.

PARAMETERS p_name TYPE c LENGTH 0.

PARAMETERS p_name( 0) TYPE c.
PARAMETERS p_carrid TYPE s_carr_id.
PARAMETERS p_chk AS CHECKBOX DEFAULT 'X'.

Listing 1. Parameters Keyword Example

The name of the parameter field para (in the syntax shown in Listing 1.1) can con-
tain a maximum of eight characters. This statement is allowed in the global decla-
ration part of the program.

Similar to the DATA statement, the length can only be specified in the PARAMETERS
statement if the data type specified in TYPE_OPTIONS has a generic length (types c,
n, p, and x).

14
 Selection Screen Overview 1.1

The PARAMETERS statement has the following effects:

Declares a global variable of the specified length and type in the program.

Creates an input field with the same name and corresponding type in the new
row of the current selection screen. The length of the input field on the screen
is determined from the parameter definition. The maximum visible length of
the input field is 45, so if the parameter length is more than 45, the field will
be displayed with movable content. The visible length of the field can be con-
trolled using the VISIBLE LENGTH addition with the PARAMETERS keyword.

Automatically creates a label for each field to the left side of the input field. The
maximum length of the field label is 30, and it displays either the name of the
parameter or the selection text to which the parameter is assigned in the text
elements (see Section 1.1.4) of the program.

Allows for the attributes of the screen elements to be modified by passing

SCREEN_OPTIONS during the declaration of the parameters.

In the following subsections, we’ll discuss the type options, screen options, and
value options that can be supplied with the PARAMETERS statement.

TYPE_OPTIONS

The PARAMETERS keyword can be supplied with different type options. These
options define the data type of the parameter. If no type options are specified, the
default option is TYPE c with LENGTH 1. The data type can be defined by referring
to an existing data type of the program, to a data object, or to a data type from
ABAP Data Dictionary.

If the PARAMETERS field is referred to a data type from ABAP Data Dictionary, it
adopts all the screen-relevant properties (such as field labels or input helps)
defined for the data type in ABAP Data Dictionary. If a domain is attached to the
data element, conversion routines defined in the domain will be executed to con-
vert the data to internal and external formats during the data transport from and
to the input field, respectively.

There are three ways to provide TYPE_OPTIONS:

TYPE data_type [DECIMALS dec]

LIKE dobj

LIKE (name)

15
1 User Interaction

The following subsections look at each of these options.

TYPE data_type [DECIMALS dec]

The TYPE data_type [DECIMALS dec] addition types the parameter with data_
type, where data_type may be any of the following:

A predefined ABAP type, with the exception of f and xstring;

A non-generic data type from ABAP Data Dictionary;

A non-generic public data type of a global class; or

A user-defined elementary data type from the same program (which is not of
the type f or xstring), already defined using the TYPES keyword

If the predefined TYPE p (packed decimal) is specified, the DECIMALS addition can
be used to define the number of decimal places.

If the parameter is referred to a data element to which a domain of TYPE CHAR,

LENGTH 1, and the fixed values "X" and a space is attached, the input field on the
selection screen is automatically displayed as a checkbox.

The following is an example of an elementary data type:

PARAMETERS p_carrid TYPE c LENGTH 3.

The next example automatically inherits the (F1) and (F4) help from ABAP Data
Dictionary and refers to the data element:

PARAMETERS p_carrid TYPE s_carr_id.

The following example is a declaration of a parameter with reference to the com-

ponent carrid of the database table spfli:

PARAMETERS p_carrid TYPE spfli-carrid.

LIKE dobj
Using the LIKE dobj addition, the parameter adopts all the properties of a data
object dobj already declared in the program.

Here’s an example of this addition in use:

DATA v_carrid TYPE s_carr_id.

PARAMETERS p_carrid LIKE v_carrid.

11
 Selection Screen Overview 1.1

TYPE vs. LIKE

TYPE is used to refer to an elementary data type, local data type in a program, or data
type in ABAP Data Dictionary. LIKE is used to refer to another data object in the pro-
gram.
To support backward compatibility, it’s still possible to use LIKE to refer to an ABAP
Data Dictionary table or flat structure; however, this usage is obsolete and should be
avoided.

LIKE (name)
The LIKE (name) addition allows you to supply the field reference dynamically.
name expects a flat character data object containing the name of a component in a
flat structure from ABAP Data Dictionary in uppercase. The parameter is created
internally with data TYPE c and LENGTH 132 , but it’s displayed on the selection
screen with a length 2, field label, input help, and field help as per the data type
specified in name.

Listing 1.3 shows an example of dynamically assigning the data type for the input
field. In this example, we’re passing the field name SCOL_FLIGHT_MEAL-CARRID at
runtime. The statement comp = 'SCOL_FLIGHT_MEAL-CARRID' in the example is exe-
cuted before the selection screen is called because it’s maintained under the AT
SELECTION-SCREEN OUTPUT event. The ABAP runtime environment triggers various
selection screen events that we can maintain in the program to process selection
screens.

You’ll learn about various selection screen events in detail in Chapter 14.

DATA comp TYPE c LENGTH 30.

PARAMETERS p_dyn LIKE (comp).
AT SELECTION-SCREEN OUTPUT.
comp = 'SCOL_FLIGHT_MEAL-CARRID'.

Listing 1.3 Dynamically Assigning Data Type for Input Field

In Listing 1.3, the keyword AT SELECTION-SCREEN OUTPUT defines an event that

ensures the code under it is executed before the selection screen is called. Because
this event is triggered before showing the selection screen to the user, we can
make use of it to dynamically assign the properties to the selection screen field.

We’ll explore all the program events in Chapter 7.

17
1 User Interaction

SCREEN_OPTIONS

These options allow you to manipulate screen fields, including declaring the
input field as a required field or hiding the input field on the selection screen.
Using SCREEN_OPTIONS, the input field can be displayed as a checkbox, radio but-
ton, or dropdown list box.

The following subsections look at the different additions for SCREEN_OPTIONS.

OBLIGATORY
The OBLIGATORY addition defines the input field on the selection screen as a
required (obligatory) field. The program can’t be executed if the obligatory field is
empty. The runtime system automatically performs a validation to check if all
obligatory fields are filled with input values when the user selects the Execute
function (F8) to exit the selection screen. If the obligatory field isn’t filled, the
user can only use the functions Back, Exit, or Cancel to leave the selection
screen.

An example of this addition is as follows:

PARAMETERS p_carrid TYPE s_carr_id OBLIGATORY.

NO-DISPLAY
When the NO-DISPLAY addition is used, no screen elements are generated for the
parameter on the selection screen. This is useful when you want to use the param-
eter only as part of the interface defined by the selection screen in an executable
program that can be supplied with a value by the calling program with the SUBMIT
statement. The SUBMIT statement is used to execute an executable program inter-
nally from another program.

An example of this addition is as follows:

PARAMETERS p_carrid TYPE s_carr_id NO-DISPLAY.

VISIBLE LENGTH vlen

The VISIBLE LENGTH vlen addition controls the visible length of a screen field.
Here, vlen is entered directly as a positive number. If vlen is less than the length
of the parameter and less than the maximum visible length (45), then the input
field is displayed as per the length defined in vlen, with movable content. Other-
wise, the addition is ignored.

18
 Selection Screen Overview 1.1

An example of this addition is as follows:

PARAMETERS: p_carrid TYPE s_carr_id VISIBLE LENGTH .

AS CHECKBOX
The AS CHECKBOX addition generates the input field as a checkbox with the corre-
sponding description next to it on the right. The value of the field is filled with
'X' or a space when the checkbox is selected or deselected, respectively. The
checkbox can be selected by default by assigning a default value 'X' during the
declaration. This parameter must be created with TYPE c and LENGTH 1. Check-
boxes are used to allow multiple selection.

An example of this addition is as follows:

PARAMETERS p_chk AS CHECKBOX.

PARAMETERS p_chk AS CHECKBOX DEFAULT 'X'.

RADIOBUTTON GROUP
The RADIOBUTTON GROUP addition generates the input field as a radio button with
the corresponding description next to it on the right. The radio button is selected
if the value of the field is X; otherwise, it isn’t selected.

Radio buttons are always grouped together because they enable the user to select
from several options. Only one of the radio buttons can be selected at once in a
group. Groups define the radio button groups for the parameter. Two or more
radio buttons are assigned to the same group by entering the name of the group
directly as a character string with a maximum of four characters. Within a selec-
tion screen, there must be a minimum of two parameters in the same radio but-
ton group. There cannot be more than one radio button group with the same
name in one program.

In a radio button group, only one parameter can be selected by default, which
means that the DEFAULT addition can be used with only one parameter of the
group. By default, the first parameter in a radio button group is set to the value X
and the rest are set to space. This parameter must be created with TYPE c and

LENGTH 1.

An example of the radio button group is shown in Listing 1.4.

PARAMETERS: p_day RADIOBUTTON GROUP rb1,

p_month RADIOBUTTON GROUP rb1 DEFAULT 'X'.

19
1 User Interaction

PARAMETERS: p_hour RADIOBUTTON GROUP rb ,

p_sec RADIOBUTTON GROUP rb .
Listing 1.4 Radio Button Group