SELECTION SCREENS

Events
For selection screens to be built and used in a program, the first things to understand are
events. Events are processing blocks, sections of code specific to the selection screens.
The structure of an event starts with the event keyword, but does not have an ending
keyword. The end of the event block of code is implicit, because the beginning of the next
event will terminate the first, or the code itself will end.

When executable programs are run, they are controlled by a predefined process in the
runtime environment, and a series of processes are called one after another. These proc-
esses trigger events, for which event blocks can be defined within the program. When a
program starts, certain events work in a certain order.

At the top level is the SAP Presentation Server (Usually the SAP GUI), seen by the end user,
with its selection screen and list output. When a program starts, from the left, with the
declaration of global variables, the system will check to see if any processing blocks are
included and will follow the sequence of events detailed above to execute these.
 SELECTION SCREENS

The initialization event block of code will only be run once, and will include things like the
setting up of initial values for fields in the selection screen. It will then check whether a
selection screen is included in the program. If at least one input field is present, control
will be passed to the selection screen processor.

This will display the screen to the user, and it can then be interacted with. Once this is
complete, the ‘at selection screen’ event block will process the information, and this is
where one can write code to check the entries which have been made. If incorrect values
have been entered, the code can catch these and can force the selection screen to be dis-
played again until correct values are entered. Error messages can be included so that the
user then knows where corrections must be made.

The ‘start of selection’ event block then takes control once the selection screen is filled
correctly. This can contain code for, for example, setting up the values of internal tables or
fields. There are other event blocks, which are visible in the diagram and there could be a
number of others. The ones discussed here though, tend to be the main ones which would
be used when working with selection screens to capture user input, which will then be
used to process the rest of the program.

Once all of these event blocks have been processed, control is handed to the list proces-
sor, which will output the report to the screen for the user to see. The list screen occa-
sionally can be interactive itself, and the code in the event block ‘at line selection’ visible
in the diagram takes responsibility for this.

This chapter will focus on creating the selection screen and making sure the user enters
the correct values for the report, as well as ensuring the selection screen has a good inter-
face.

Intro to Selection Screens

ABAP reports have 2 types of screens, selection screens and list output screens. The out-
put window has already been used to produce list output screens. Selection screens are
very commonly used. Indeed, when entering the ABAP editor, you are using a type of se-
lection screen:
 SELECTION SCREENS

We will focus on reproduced this type of screen for use by our programs. These will allow
the user to select data which will be used as parameters in the program. When one cre-
ates a selection screen, in fact a dialogue screen is being created, but one does not have
to write the dynpro code oneself. Only specific statements need to be used, and the sys-
tem will take care of the screen flow logic itself.

List screens and selection screens are both dialogue programs. Every one of these has at
least one dynpro which is held in what is called a module pool. A dynpro report program
called ‘standard selection screen’ is called and controlled automatically by the runtime
environment while the program is executed. The dynpro number itself is 1000. The user
will only see the screen when the programmer includes the parameters in their program
using specific ABAP statements. It is these ABAP statements which cause the screen to be
generated and displayed to the user. This means it is easy for the programmer to start
writing their own programs without having to think about code to control the screen.

Creating Selection Screens

Create a brand new program in the ABAP editor, called Z_SCREENS_1.

First, the initialization event will be looked at. This is the first thing to be triggered in a
program. In this example, imagine one wanted to know the last employee number which
was used to create a record in the zemployees table. The initialization event is the correct
place for this type of code, so that this information can then be displayed on the selection
screen, alerting the user that values greater than this should not be entered as they will
not return results.
 SELECTION SCREENS

Begin by declaring the TABLES statement for zemployees. Then declare a DATA statement
to hold the value of the last employee number that has been used in the table. This can be
done with a work area declared LIKE the employee number field of the table.

Type “INITITIALIZATION.”, to begin the event block, followed by a SELECT statement

where all records from zemployees are selected, and the work area is populated with the
employee number field:

Then add a WRITE statement for the work area to output to the screen after the loop.
Note that as the SELECT statement is a loop and does not contain a WRITE statement in-
side it, the WRITE statement at the end only writes the final employee number which
populates wa_employee, the last one which was used.

At Selection Screen
The “at selection screen” event is the next event block in the process. This will always be
executed, if present, before the report can be processed. This, then, would be the ideal
place to check the value which has been entered by the user as a new employee number.
The entry screen will be looked at later, but here some code will be written which will al-
low some kind of error message to be shown if an incorrect value is entered, telling the
user to correct their entry.

The PARAMETERS statement will be used, though will not be gone in detail until later. This
statement, allows you to declare a parameter input box which will appear on the screen.
This works similarly to a DATA statement - “PARAMETERS: my_ee LIKE zemployees-
 SELECTION SCREENS

employee.”, declaring the parameter as having the same properties as the employee
number field.

Then declare the AT SELECTION-SCREEN event. This is declared with the addition ON, and
my_ee added. This specifies that the 'at selection screen' block refers specifically to this
parameter.

After this, an IF statement can be written, displaying an error message if the parameter
value my_ee entered by the user is greater than the value held in wa_employee, the last
employee number used:

As mentioned earlier, there is no need to terminate event blocks, as they are terminated
automatically when a new one begins. Hence, the INITIALIZATION block ends as soon as
the AT SELECTION-SCREEN block begins.

Parameters
Now, the PARAMETERS statement will be looked at in greater detail. Having defined the
my_ee variable using this statement, the system will now automatically know that a selec-
tion screen is going to be generated. This statement is all that is necessary to display a
field in a selection screen. If you display just the PARAMETERS variable on the screen, it
will appear like this:
 SELECTION SCREENS

The syntax for PARAMETERS is very similar to the DATA statement. A name is given to the
variable, a type can be given or the LIKE statement can be used to give the same proper-
ties as another field already declared. An example appears below, followed by the output
screen when this is executed:

The DOB parameter takes on the same attributes as the DOB field in the table, to the ex-
tent that it will even offer a drop-down box to select a date. The my_numbr parameter is
not related to another field as has been declared as an integer type parameter. Addition-
ally, note that parameter names are limited to 8 characters. Also, just like the DATA
statement, a parameter can hold any data type, with the one exception, floating point
numbers. You will notice also that the parameters in the output are automatically given
text labels. The name of the parameter from the program, converted to upper case is used
by default.

Now, some additions to the PARAMETERS statement will be examined.

DEFAULT
If you add this to the end of the statement follow by a value, the value will appear in the
input box on the output screen giving a default value that the user can change if they
wish.
 SELECTION SCREENS

OBLIGATORY
To make the field mandatory for the user, the addition OBLIGATORY is used. A small tick-
box will then appear in the field when empty, to indicate that a value must be inserted
here. If one tries to enter the report with this empty, the status bar will display a message
telling the user an entry must appear in this field:

Automatic Generation of Drop-Down fields

For the next parameter, the zemployees2 table will be used. This must be added to the
TABLES statement at the top of the program. A new parameter, named my_g here is set
up for gender:

Since a number of values allowed to be entered for the gender field have been suggested
in the table itself, a drop down box will appear by the parameter in the output window.
Here one can see the ABAP dictionary working in tandem with the program to ensure that
values entered into parameters correspond with values which have been set for the field
in the table:
 SELECTION SCREENS

If one manually types an illegitimate entry into the gender box, an error message will not
appear. Here, the VALUE CHECK addition is useful, as it will check any entry against the
valid value list which is created in the ABAP dictionary. Now if one tries to enter an invalid
value for the field, an error message is shown in the status bar:

(After this example, the zemployees2 table and gender parameter can be removed.)

LOWER CASE
By default parameter names are converted to upper case, to get around this one must use
the LOWER CASE addition. Create a new parameter named my_surn and make it LIKE
zemployees-surname field. Give this a default value of ‘BLOGS’ and then add the LOWER
CASE addition. When this is output, BLOGS still appears in upper case, but lower case let-
ters can be added to the end of it. If these were entered without the LOWER CASE addi-
tion, they would automatically convert to upper case:
 SELECTION SCREENS

There are other additions which can be included with parameters, but these are generally
the most common ones. To look at others, one can simply select the PARAMETERS state-
ment, and press F1 for the ABAP help screen, which will explain further additions which
can be used.

Check Boxes and Radio Button Parameters

Check boxes and radio buttons can both be used to simplify the task of data entry for the
end user. These are both forms of parameters.

A check box must always be of the character type ‘c’ with a length of 1. The contents
stored in this parameter will either be an ‘x’, when it is checked, or empty when it is blank.

Define a new parameter called my_box1. Since this is type c, the type does not have to be
declared. The field name is then followed by “as checkbox”. Note that the output differs
slightly from other parameters by seeing the box on the left and the text to its right:

Radio buttons are another common method for controlling the values stored in fields. A
normal parameter field allows any value to be entered, while a check box limits the values
to 2. Radio buttons, however, give a group of values which the user must choose one op-
tion from. Again, these are of data type c with 1 character.

To create a group of 3 radio buttons, 3 parameter fields must be set up. Each radio button
must be given a name, in this example to select between colours (don’t forget, parameter
names are limited to 8 characters), followed by “radiobutton”. These are then linked to-
gether by adding the word “group”, followed by a name for the group, here “grp1”. This
can be seen in the image below:
 SELECTION SCREENS

Select-Options
Next we will take a look at SELECT-OPTIONS. Parameters are useful for allowing the user
to select individual values.. However, when multiple values are required, rather than set-
ting up many different parameters, the select-options statement can be used.

The first thing to consider here is that internal tables will be used to store the values en-
tered by the user. A detailed discussion regarding internal tables will be returned to, but
for now, only what is necessary for select options will be looked at.

When a user wants to enter multiple individual values, or select a value range, these must
be stored in a table in memory which the program can use. The internal tables to be used
here are, similarly to parameters, limited to 8 characters and contain 4 fields which are
defined when the statement is created. These fields are “sign”, “option”, “low” and
“high”. The image below demonstrates the structure of this table:

When a user makes a choice, filling in a selection field on the screen, whether this is a sin-
gle value or a range of values, a record is generated and put into this internal table. This
table allows the user to enter as many records as they wish, which can then be used to
filter the data.
 SELECTION SCREENS

The “sign” field has a data type of c, and a length of 1. The data stored in this field deter-
mines, for each record, whether it is to be included or excluded from the result set that
the final report selects from. The possible values to be held in this field are ‘I’ and ‘E’, for
‘inclusive’ and ‘exclusive’.

The “option” field also has a type of c, but this time a length of 2. This field holds the se-
lection operator, such as EQ, NE, GT, LT, GE, LE (in order, as discussed previously: equal to,
not equal to, greater than, less than, greater than or equal to, less than or equal to), as
well as CP and NP. If a wild card statement is included here (such as * or +), the system will
default this to CP.

The “low” field holds the lower limit for a range of values a user can enter, while the
“high” field is the upper limit. The type and length of these will be the same as those for
the database table to which the selection criteria are linked.

The reason for using select-options is that parameters only allow for one individual spe-
cific value to be used. If for example, one is using parameters to select from the DOB field
in the zemployees table, these are very specific and so are likely to return, at best, one
result, requiring the user to know the exact date of birth for every employee. The select-
options statement allows one to set value ranges, wild cards and so on so that any selec-
tion within that will return results.

First, type the statement SELECT-OPTIONS and then give a name to the field to be filled,
for example my_dob. To declare the type, the addition FOR is used. This then link this to
zemployees-dob:

When this is output, 2 fields will appear, plus a ‘Multiple selection’ button:

A value range can be selected by entering the low value into the left field and the high
value in the right field. These two fields both include calendar drop down menus, making
 SELECTION SCREENS

entry here even easier. If the ‘multiple selection’ button is clicked, a new pop-up box ap-
pears:

The fields here allow multiple single records, or value ranges to be searched for, as well as,
in the case of the latter two tabs, excluded from one’s search results. All of the fields here
as well correspond to the initial data type, and so will all feature calendar drop-downs.
The buttons along the bottom add functionality, allowing values to be copied and pasted
into the rows available, and indeed to create and delete rows among other options. Addi-
tionally on the selection screen, if one right-clicks either field and chooses ‘options’, a list
of the logical operators will be offered, allowing further customisation of the value ranges
selected. This can also be done in the multiple selection box:
 SELECTION SCREENS

By filling in the fields offered via the SELECT-OPTIONS statement on the selection screen,
each of the fields of the internal table can then be filled depending on the options chosen,
telling the system exactly which values it should (and should not) be searching for.

Select-Option Example
With the select-options defined, some code will now be added.

Create a SELECT statement, selecting all the records from zemployees. Then, inside the
loop, add an IF statement, so that if a record from the zemployees table matches the
value range selected at the selection screen, the full record is written in the output screen.

The IN addition ensures that only records which meet the criteria of my_dob, held in the
internal table, will be included, and where they do not, the loop will begin again:
 SELECTION SCREENS

Put a breakpoint on the SELECT statement, so that you can watch the code’s operation in
debug mode. When you execute the code the selection screen will be displayed. Initially,
do not enter any values for the DOB field. Execute the program and the debugger will ap-
pear. Double click the my_dob field in the field mode. It will be shown to be empty and an
icon will appear to the left indicating that it represents an internal table. If this is double
clicked, the contents of the internal table are shown. Here, all fields are empty as no val-
ues were inserted:

Run through the code and all of the records from the table should be written to the out-
put screen, as no specific selection criteria were set.

Run the program again but this time include a value in the DOB field of the selection
screen. This one corresponds to one of the records in the table:

As the select loop is processed, eventually a matching record will be found. When this oc-
curs, rather than skip back to the beginning of the loop, the WRITE statement is executed:
 SELECTION SCREENS

Run the program again but this time try using the multiple selection tool to select several
values for the DOB field, as well as excluding some:
 SELECTION SCREENS

The internal table now contains several entries for values to search for and to exclude
from its search:

The records stored in the select-option table for my_dob show the different types of data
the system uses to filter records depending on the entries we make in the multiple selec-
tions window. Once the program is fully executed the output window then appears like
this:
 SELECTION SCREENS

Select-Option Additions
As with most statements, there are a number of additions which can be appended to SE-
LECT-OPTIONS. Similarly to PARAMETERS, one can here use OBLIGATORY and LOWER
CASE, and others in exactly the same way. Unique to this statement, however, is NO-
EXTENSION, which prevents the multiple selection option from being offered to the user.
The ability to select a value range still exists, but extending this via multiple selections is
prevented:

Text Elements
We have already touched on the fact that when parameters and select-options are de-
clared the fields are labelled with the technical names given in the code. These fields still
must be referenced using the technical name. However, it will be much preferable for the
user to see some more descriptive text. Let’s see how we can do this by using Text Ele-
ments.

Every ABAP program is made up of sub-objects, like text elements. When one copies a
program, the list of options offered asks which parts of the program one wants to copy.
The source code and text elements here are mandatory, these are the elements which are
essential to the program.

When text elements are created, they are created in text pools, which hold all of the text
elements of the program. Every program created is language independent, meaning that
the text elements created can be quickly and easily translated to other languages without
the need for the source code to be changed.

There are three kinds of text elements which can be used in a program, selection texts,
mentioned above, are one. The other two are text symbols and list headings. Text symbols
can be created for a program so that one does not have to hard code literals into the
source code. List headings, as the name indicates, refer to the headings used when creat-
ing a report. By using these instead of hard coding them into the program, one can be cer-
tain that they will be translated if the program is then used in another language. Also, if
 SELECTION SCREENS

the headings need to be changed later on, one can just change the list headings set rather
than going into the code and doing this manually.

Selection texts allow text elements to be displayed on the screen so that the user does not
have to see the technical names for fields and the like. There are several ways to navigate
to the screen where these can be created and changed. At the initial ABAP editor screen,
there is in fact an option for creating text elements:

Alternatively, if one is already inside the program, this can be reached through the ‘Goto’
menu, ‘Text elements’ and select ‘Selection texts’:

If this is clicked, a screen will appear where selection texts can be created for all of the
technical field names which appear at the selection screen:
 SELECTION SCREENS

The third column here is for ‘Dictionary reference’, which recognises that some of these
fields are linked to fields already created in the ABAP dictionary. If one checks this box and
clicks save, the field names from the initial fields and the ABAP dictionary automatically
appear. You can of course choose not to use the text here and overwrite it yourself.

For the others fields, the text must be manually typed in, up to a 30 character limit:
 SELECTION SCREENS

Text Elements must then be activated and once this is done, they are automatically saved
and will appear on the selection screen in place of the technical names. The output screen
will now look like this:

Variants
When a user fills in a selection screen, there is the option of saving the entry. This is called
a variant:
 SELECTION SCREENS

Once this is done, a new screen appears. As long as a name and description are given, this
can be saved for use later on:

Once saved a new button appears on the selection screen next to the execute button,
named ‘Get variant’ allowing the variant entry to be recalled.
 SELECTION SCREENS

A box appears allowing a variant to be selected and when selected, the fields are popu-
lated with the data from that particular entry. Another way to create variants is via the
initial ABAP editor screen.

Choose the ‘Variants’ option. A new variant name can be entered and then the variant can
be created:

Once ‘Create’ is clicked, the selection screen appears and you can proceeds as normal,
saving the attributes of the new variant once the entries have been made. You can then
choose between displaying and changing the values and attributes of the variant (‘Values’
will show the selection screen, ‘Attributes’ the screen below. These two views can be
switched between):
 SELECTION SCREENS

The ‘Only for background processing’ check box allows you to tell the system to only use
this variant as part of a background job. Here, a job can be scheduled to run overnight so
the program does not in fact have to be monitored.

The ‘Protect variant’ option prevents other users from being able to select this variant and
using it on their reports.

‘Only display in catalog’ effectively makes the variant inactive, it will exist, but when a
user views the drop-down menu of existing variants, it will not appear.
 SELECTION SCREENS

The ‘Field attributes’ section allows the list of possible attributes displayed to be assigned
to the fields in the bottom section of the screen, via the check boxes. Experiment with the
different options available and see the results. For example, you can see that the ‘Re-
quired field’ check box for ‘Employee number’ has been filled here, as this was labelled
OBLIGATORY in the program. The P’s and one S which appear by the fields simply refer to
whether each field is a parameter or select-option.

Choose ‘Protect field’ for the Date of Birth field; it will no longer be possible to change the
value set until such time as this box is un-checked. In the image below you can see this
field has been greyed out and cannot be changed:

When large selection screens are created, users will regularly create variants so that, if
necessary, the same data can be used repeatedly when running reports, saving the time it
would take to fill in the information again and again. Unnecessary fields, or fields which
will always hold the same value can be protected so that filling in the screen becomes a
much simpler and less time consuming task for the end user.

At the ABAP editor’s initial screen, there is in fact a button which allows the program to
run with a variant, directing one straight to the selection screen with the variant’s values
already present:
 SELECTION SCREENS

The ABAP editor will likely not be accessed by the user but reports can be accessed via the
‘System’ menu, ‘Services’, and then ‘Reporting’. Selecting this presents the ’ABAP: Execute
Program’ screen, which could be described as a cut-down version of the ABAP editor
screen, minus the editing functionality. From here the program can again either be exe-
cuted directly or executed using a variant which can be selected from the menu which is
offered:
 SELECTION SCREENS

If the program is executed directly and the user then wants to use a variant, this can also
be done via the ‘Goto’ menu:

Text Symbols
We will now take a look at other text objects starting with Text Symbols. These are used to
replace literals in a program. For example, when the WRITE statement is used, one can
choose to use text symbols to reuse text which has already been set up. This also gives the
added functionality of being able to use translated text within the program. This allows
hard coded literals to be avoided and text symbols used in their place.

Text symbols effectively function as placeholders for text. So, rather than having “WRITE:
/ ‘Surname’.” multiple times in the code, you can avoid using the literal by using “WRITE:
/ text-001.” which here would refer to a text symbol which can be set up with the text
“Surname” itself.
 SELECTION SCREENS

Text symbols are always declared with the word ‘text’ followed by a dash and a three digit
number. This means that up to 1000 text symbols can theoretically be used in a program,
of which each one can be translated into as many languages as one wishes. One thing to
remember here is that text symbols are always limited to 132 characters in length.

To create a text symbol, you can use the ‘Goto’ menu, select ‘Text elements’ and then
‘Text symbols’, or you can use forward navigation. Just double-click ‘text-001’. A window
will then appear asking if you want to create this object, select ‘Yes’. The Text Elements
window will then appear and text can be entered for the new text symbol.

Here, include the word ‘Surname’. The column on the left references the text symbol id
‘001’. The two columns on the right note the text’s length and maximum length:

This can then be activated and you can step back to the program. If the code is then exe-
cuted, the word ‘Surname’ will be output twice, the first from the WRITE statement with
the literal, the second from the WRITE statement with the newly created text symbol:

It is advisable to use text symbols rather than literals as often as possible as it is much eas-
ier to change the text symbol once than to sift through the code to find and change many
literal values. Additionally, using text symbols gives the added benefit of translatability.
 SELECTION SCREENS

Text Messages
The next thing to be examined here is messages. When one wants to give feedback to the
user, literals can be used, but as stated above, this is to be avoided as far as possible. To
use messages then, these must first be stored in a message class, which is in turn stored in
a database table called T100.

At the ABAP dictionary’s initial screen, type ‘T100’ into the database table field and choose
‘Display’:

If one views the contents of this, one can see the four fields displayed. One for language
(here D, referring to German), one for the application area, one for the message code and
one for the message text:

To create new messages to be used in your program, forward navigation can be used, or
the transaction SE91 can be directly accessed:
 SELECTION SCREENS

First, create a message class. These must again follow the customer name space rules,
here beginning with the letter Z. Let’s call this ZMES1 and choose Create. Messages are
distinct from text elements as they are not themselves part of the program created. They
exist independently. They are instead stored in the T100 table. This means that messages
can be reused across many programs.

The attributes must be filled in, creating a short text. Then, in the messages tab, the text
to be used can be created:
 SELECTION SCREENS

Remember that, when the AT SELECTION-SCREEN event was created, an IF statement was
used so that if the employee number given by the user was greater than the last employee
number used in the table, a message would be displayed. Here, the text for that message
can be created:

Once the text is entered, it can be saved.

There are a number of message types which can be used, as this table explains:

A Termination The message appears in a dialog box, and the program terminates.
Message When the user has confirmed the message, control returns to the
next-highest area menu.

E Error Depending on the program context, an error dialog appears or the

Message program terminates.

I Information The message appears in a dialog box. Once the user has confirmed
the message, the program continues immediately after the MESSAGE
statement.

S Status The program continues normally after the MESSAGE statement, and
Message the message is displayed in the status bar of the next screen.

W Warning Depending on the program context, an error dialog appears or the

program terminates.

X Exit No message is displayed, and the program terminates with a short

dump. Program terminations with a short dump normally only occur
when a runtime error occurs. Message type X allows you to force a
program termination. The short dump contains the message ID.

For this example, type E, an error message, will be used. Depending on where this type of
message is used, it will have a different effect. Here, it will be used at the “at selection-
screen” and the program’s execution will pause, the error message will be displayed and
 SELECTION SCREENS

the user will be allowed to amend their entry. When the new entry appears, the event will
begin again. If an error message is used elsewhere, outside of an event in the main body
of the code, when this is triggered the program will terminate entirely.

To include the newly created message in the code, then, the syntax is “MESSAGE
e000(ZMES1).” The ‘e’ refers to the error message type, the ‘000’ to the number assigned
to the message in the message class, and then ‘ZMES1’ to the class itself:

The INITIALIZATION event will populate wa_employee with the last, highest employee
number used in the table, and then, at the AT SELECTION-SCREEN event, the value en-
tered can be checked against this. If it is higher, the error message will display. You can
monitor these values in debug mode to watch the code in action. Here, the number is
higher so, once executed, the selection screen will be returned to and the message dis-
played in the status bar:
 SELECTION SCREENS

Once a legitimate, lower value is entered, the program will continue as normal without
triggering the error message.

An addition which can be used with the MESSAGES statement is WITH. Here, a field can be
specified, for example to display the invalid value which was entered by the user in the
message itself. The WITH addition allows up to 4 parameters to be included in the error
message. To do this, one must ensure the error message is compatible.

Create another message in the message class screen, this time with an & character. When
used in conjunction with the WITH addition, this character will then be replaced by the
value in the specified parameter:

Save the new message, add “WITH my_ee” to the MESSAGES statement and change the
number of the message referenced in the code to the new 001 message:

As messages created are not specific to the program itself, but can be used across the en-
tire system, it is usually worth checking if an appropriate message for the task you are per-
forming already exists, rather than continually setting up new messages.
 SELECTION SCREENS

Skip Lines and Underline

Now, a look will be taken at formatting selection screens. This will allow the screen to be a
lot easier to navigate and so on for the end user. Parameters and select-options have al-
ready been set up, but as yet no layout options have been implemented allowing the sys-
tem to place the objects by itself. This is generally not sufficient. For example, when a
group of radio buttons appear, they should be distinct and positioned in a group on their
own, clearly separated from other parts of the screen.

The SELECTION-SCREEN statement, and its associated additions allow this kind of format-
ting to be done. One must locate where in the code the screen layout begins to be re-
ferred to. Here, this is at the top when PARAMETERS is declared. In the line above this,
type the statement SELECTION-SCREEN. Additions must then be added.

First, to add blank lines you can use the SKIP addition, followed by the number of lines to
be skipped. If you only want to skip 1 line then the number can be omitted as this is the
default values. This line of code must then be moved to the place where you want the line
to be skipped. Place it under the my_ee parameter. Note that the PARAMETERS chain is
now broken, so another PARAMETERS statement must be added:
 SELECTION SCREENS

To add a horizontal line, the ULINE addition can be used:

There are further additions which can be added to ULINE to determine its position and
length. The code in the image below sets the position of the line to the 40th character
from the left of the screen, and its length is set to 8 characters:
 SELECTION SCREENS

Comments
Comments allow text to be placed on screen without creating new fields. The SELECTION-
SCREEN statement is again used, with the addition COMMENT. Similar additions to ULINE
can be used to set the position and length of the comment. This is then followed by either
a text element which has already been set, or a field name. This is not declared with a
DATA statement, but is determined by the length which the comment is set. Here, the text
element text001 is used, which reads ‘Surname’, and this will appear 40 characters from
the left:

If you do not want to use a text element, a new field can be created here. Copy the initial
SELECTION-SCREEN statement and add the new variable “comm1”. This variable is cur-
rently empty and must be given a value. This must be added in the INITIALIZATION part of
the code, so that it is initialised when the program starts. Here, write “comm1 = ‘Hello
SAP’.”:
 SELECTION SCREENS

Format a Line and Position

Now, let’s take a look at how to format a single line on the selection screen. When indi-
vidual lines for the selection screen are defined, the start and end of these lines must be
declared, and in between these lines the parameters and select-options appear.

Above the formatting code already created, type “SELECTION-SCREEN BEGIN OF LINE.”,
and then underneath “SELECTION-SCREEN END OF LINE.” Anything appearing between
these statements will now all appear on the same line. Then, alter the formatting code
slightly so that this will work, removing the ULINE statement, moving the text001 com-
ment (which reads ‘Surname’) to the first space on the line, and the comm1 comment
(reading ‘Hello SAP’) to the 20th space and change the length of this to 10 characters. Also,
remove the /n which put these on a new line. Finally, add a new PARAMETERS statement
beneath the second comment in the code, named ‘ABC’, with a length of 5:
 SELECTION SCREENS

You can now see that the code between the BEGIN and END OF LINE statements now all
appears on one line; its formatting determined by the positions and lengths assigned to
each statement. Note that here the parameter was not automatically given a description
(the technical name of the field) as others have been. This is because specific comments
have been used on the same line. When you are formatting a line in this way, he com-
ments can be used to act as descriptions for the field.

Another addition, which can only be used within BEGIN and END OF LINE, is POSITION.
This is not commonly used because this can effectively be set by alternate methods, as
above. However, if one desires, the position of the next element can be set separately.
Here, the parameter will appear 30 spaces into the new line:

Note that here the technical name still does not appear, as the parameter is still between
the BEGIN and END OF LINE statements.

There is also a further option which can be included with the POSITION addition. The de-
fault positions of parameters and select-options on the screen are referred to as ‘position
low’ for the left hand side, where standard parameters and the low end of value ranges
appear, and ‘position high’ for the right hand side, where the upper end of a value range
would appear. These default positions can be used with the POSITION addition. To place a
parameter in the ‘position high’ position, you would include pos_high at the end of the
statement:
 SELECTION SCREENS

You can see that the parameter now matches up with the ’position high’ default value
when compared to the upper end of the Date of Birth value range. Unsurprisingly, this is
replaced with pos_low to make it correspond to the default ‘position low’ column.

Element Blocks
When you are creating selection screens, it is common practice to group certain fields to-
gether. You can make use of these element blocks, which will draw frames around the cer-
tain groups of fields which are designated. These frames can then be given frame labels.
Bear in mind when looking at these it is possible to nest element blocks within other ele-
ment blocks, allowing individual sections of the selection screen to be subdivided.

The syntax for this is very similar to that of BEGIN and END OF LINE. Above where these
statements were tested before, add the code “SELECTION-SCREEN BEGIN OF BLOCK”, fol-
lowed by a name for this block, here “myblock1”. To then add a frame to the block, the
WITH FRAME addition is then used. The frame can then be given a title using, like com-
ments, either a text element or separately defined variable. This is done after the WITH
FRAME addition, adding TITLE and then, here ‘text-001’, which as before contain the val-
ues ‘Surname’.
 SELECTION SCREENS

Having done all of this, you must remember to then use END OF BLOCK followed by the
block name so that the system knows which block is ending:

Element blocks, when used correctly, add context to the selection screen, making it easier
for the end user to understand the screen entry requirements.