How Do SAP ABAP Selection Screens Works?

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 processes 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.

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 displayed 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 processor, which will output the report to the screen for the user to see. The list screen occasionally can be interactive itself, and the code in the event block ‘at line selection’ visible in the diagram takes responsibility for this.

This article 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 interface.

Intro to Selection Screens

ABAP reports have 2 types of screens, selection screens and list output screens. The output 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 selection screen:

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 creates 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 system 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.

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 “INITIALIZATION.”, 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 inside 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 allow 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-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 selection 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:

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 properties 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 extent 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. Additionally, 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.

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:

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 letters can be added to the end of it. If these were entered without the LOWER CASE addition, they would automatically convert to upper case:

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 statement, and press F1 for the ABAP help screen, which will explain further additions which can be used.