Each screen that a user sees in the R/3 System belongs to an application program. Screens send data to, receive data from, and react to the user’s interaction with the input mask. There are three ways to organize screen input and output. These differ in the way in which they are programmed, and in how the user typically interacts with them.

Screens in the R/3 System also contain a menu bar, a standard toolbar, and an application toolbar. Together, these three objects form the status of the screen. Each status is an object of its corresponding application program. It is a standalone part of the screen . Since it does not expressly belong to one screen, it can be reused in any number of screens. You define statuses using the Menu Painter in the ABAP Workbench. You can define your own statuses for screens and lists. Selection screens have a fixed status.

The following sections describe the different types of screen in more detail.

Each screen contains an input mask that you can use for data input and output. You can design the mask yourself. When the screen mask is displayed by the SAPgui, two events are triggered: Before the screen is displayed, the Process Before Output (PBO) event is processed. When the user interacts with the screen, the Process After Input (PAI) event is processed.

Each screen is linked to a single PBO processing block and a single PAI processing block. The PAI of a screen and the PBO of the subsequent screen together form a dialog step in the application program.

The screen language is a special subset of ABAP, and contains only a few keywords. The statements are syntactically similar to the other ABAP statements, but you may not use screen statements in ABAP programs or ABAP statements in the screen flow logic. The most important screen keywords are MODULE, FIELD, CHAIN, and LOOP. Their only funciton is to link the processing logic to the flow logic, that is, to call modules in the processing logic, and control data transfer between the screen and the ABAP program, for example, by checking fields.

The input/output mask of a screen contains all of the normal graphical user interface elements, such as input/output fields, pushbuttons, and radio buttons. The following diagram shows a typical screen mask:

All of the active elements on a screen have a field name and are linked to screen fields in shared memory. You can link screen fields to the ABAP Dictionary. This provides you with automatic field and value help, as well as consistency checks.

When a user action changes the element, the value of the screen field is changed accordingly. Values are transported between screens and the processing logic in the PAI event, where the contents of the screen fields are transported to program fields with the same name.

Each screen calls modules in its associated ABAP program which prepare the screen (PBO) and process the entries made by the user (PAI). Although there are ABAP statements for changing the attributes of screen elements (such as making them visible or invisible), but there are none for defining them.

Dialog screens enable the user and application programs to communicate with each other. They are used in dialog-oriented programs such as transactions, where the program consists mainly of processing a sequence of screens. Essentially, you use screens when you need more flexibility than is offered by selection screens or lists.

Selection screens are special screens used to enter values in ABAP programs. Instead of using the Screen Painter, you create them using ABAP statements in the processing logic of your program. The selection screen is then generated according to these statements. The screen flow logic is supplied by the system, and remains invisible to you as the application programmer.

You define selection screens in the declaration part of an ABAP program using the special declaration statements PARAMETERS, SELECT-OPTIONS and SELECTION-SCREEN). These statements declare and format the input fields of each selection screen. The following is a typical selection screen:

The most important elements on a selection screen are input fields for single values and for selection tables. Selection tables allow you to enter more complicated selection criteria. Selection tables are easy to use in ABAP because the system automatically processes them itself. As on other screens, field and possible values help is provided for input fields which refer to an ABAP Dictionary field. Users can use pre-configured sets of input values for selection screens. These are called variants.

You call a selection screen from an ABAP program using the CALL SELECTION-SCREEN statement. If the program is an executable (report) with type 1, the ABAP runtime environment automatically calls the selection screen defined in the declaration part of the program. Selection screens trigger events, and can therefore call event blocks in ABAP programs.

Since selection screens contain principally input fields, selection screen dialogs are more input-oriented than the screens you define using the Screen Painter. Dialog screens can contain both input and output fields. Selection screens, however, are appropriate when the program requires data from the user before it can continue processing. For example, you would use a selection screen before accessing the database, to restrict the amount of data read.

Lists are output-oriented screens which display formatted, structured data. They are defined, formatted, and filled using ABAP commands. The system displays lists defined in ABAP on a special list screen. As with selection screens, the flow logic is supplied by the system and remains hidden from the application programmer.

The most important task of a list is to display data. However, users can also interact with them. Lists can react to mouse clicks and contain input fields. Despite these similarities with other types of screen, lists are displayed using a completely different technique. Input fields on lists cannot be compared with those on normal screens, since the method of transferring data between the list and the ABAP program is completely different in each case. If input fields on lists are linked to the ABAP Dictionary, the usual automatic field and possible values help is available. The following is a typical list:

You define lists using a special set of statements (the list statements WRITE, SKIP, ULINE, NEW-PAGE and so on) in the processing blocks of ABAP programs. When these statements are executed, a list is composed within the system. An internal system program called the list processor is responsible for displaying lists and for interpreting user actions in the list. Lists are important because only data in list format can be sent to the R/3 spool system for printing.

In an ABAP program, you can use the LEAVE TO LIST-PROCESSING statement to define the next screen as a list. If the ABAP program is an executable (report) with type 1, the ABAP runtime environment automatically calls the list defined in your program. A single program can be responsible for a stack of up to 21 lists. From one basic list, you can create up to 20 details lists. User actions on a list screen trigger events, and can thus call event blocks in the ABAP program.

Lists are output-oriented. When users carry out actions on a list screen, it is normally to use part of the list contents in the next part of the program, and not to input values directly. Using lists is appropriate when you want to work with output data, to print data or when the user’s next action depends on output data.