The Screen

A screen not only consists of its layout with input/output fields, pushbuttons and other screen elements but also a processing logic (source code excerpts that are processed as the pre-/postprocessing of the screen display).

The fact that the ABAP Dictionary is integrated in the system means that automatic consistency checks for screen input fields are provided. These checks include type checks, foreign key checks, and fixed value checks. All of these checks are automatically supplied with information from the ABAP Dictionary.

Checks like the ones above can be complemented by other program-specific checks. There are techniques available for screens that allow you to control the order in which checks are performed and, if errors occur, to make the fields input-ready again, where appropriate.

The layout can be designed very flexibly, with input fields, output fields, radio buttons, check fields and, most importantly, pushbuttons with which the corresponding functions of the program can be executed.

Screens have the same formatting options as lists and selection screens: Fixed point numbers and dates are formatted according to the settings in the user master record; the time is set to hh:mm:ss; sums of money are formatted according to the content of the currency field, and physical measures (lengths, weights, ...) are formatted according to the content of a unit field.

In principle, there are two options for starting a screen sequence:

1. By calling the first screen (CALL SCREEN statement) from a processing block in your program
2. By creating a transaction that references the program and the first screen (dialog transaction).

After a screen is processed, the statically or dynamically defined screen sequence is processed. The formal next screen 0 returns processing to the point where the screen was called or ends the dialog transaction.

Screens can be created in the following program types:

Executable program (report)
Screens are used in executable programs in order to display data in addition to the list output, or to replace the list output completely. In addition, there is also the possibility of using screens to enter and change data in the list. For the purpose of reusability and data encapsulation, you should no longer create screens directly in reports, but use screens in function groups instead.

function group
Screens in function groups can be addressed using dialog transactions. You can also start such screens from the source code of a function module using the CALL SCREEN statement. This enables you to make a screen or a screen sequence easily available with a defined interface for reuse. Function groups are the recommended program type for creating screens.

module pool
Screens in module pools can only be addressed using dialog transactions. In contrast to screens in function groups, you cannot encapsulate them and provide them with a well-defined external interface.

For this reason, you should avoid creating new module pools where possible. Always use function groups instead, even if addressing the screen using function modules has not (yet) been planned.

Each screen has the following components:

Properties (attributes)
Properties contain, for example, a four-digit number as the screen name, a short text, information on the screen type (for example, Normal for full screen size) and also specify the default next screen.

Layout
You can place input/output fields, texts, pushbuttons, and other elements on your screen. Such elements are called screen elements.

Element list
Lists all screen elements including their attributes such as position, size, data type, and so on.

Flow logic
The flow logic of a screen consists of the PBO (Process Before Output) and the PAI (Process After Input). PBO contains references to processing blocks (PBO modules) that are processed in preparation for the screen display (for example, data selection) before the screen is sent. PAI contains references to processing blocks (PAI modules) that are processed as a reaction to user input and actions (for example, save data).

Using the graphical Screen Painter, you can design the layout of the screen (toolbar). You also have the following maintenance functions using the three pushbuttons depicted in the above graphic:

Maintain element attributes
In a dialog box, all attributes for the selected screen element are displayed for maintenance.

Get Dictionary or program fields
You can use a dialog box to create screen fields with reference to fields from Dictionary structures or fields defined within the program.

Show element list
Shows all available screen elements including their attributes for maintenance.

In the following sections, a program will be developed in several steps that will enable you to display the data for individual flight connections.

The program comprises a sequence of two screens. On the first screen, the user chooses a flight connection. On the second screen, the details for this connection are displayed.

The screen sequence is started by a dialog transaction. If the user chooses the Continue pushbutton on the first screen, the entries are processed, the data is read from the database and the system navigates to the second screen.

On the second screen, the flight connection data is displayed. If the user chooses the Back pushbutton, the system returns to the first screen, where another flight connection can be selected.

If the user chooses the Exit pushbutton, the system exists the screen sequence. In this case, the dialog transaction is cancelled.

Screens, Pushbuttons and Navigation

At the first level of our example, two screens will be created on which pushbuttons are located. The program is to be implemented in such a way that after a pushbutton has been selected, you navigate to the other screen, or exit the screen sequence. The screen sequence is to be started by a dialog transaction.

This section deals with the following:

• Creating screens
• Flow logic of a screen in PBO and PAI event blocks
• PBO and PAI modules as processing blocks for the corresponding events
• Implementing pushbuttons and evaluating user actions
• Creating dialog transactions

There are several ways to create a screen:

Using the Object Navigator
You can create a new program object (screen) for your program on the object list in the navigation area using the context menu for your program (see above graphic).

By forward navigation from the ABAP Editor
In the ABAP Editor, double-click the screen number to create a screen (in the CALL SCREEN nnnn statement). The system automatically opens the Screen Painter for maintaining the new screen.

When you create a screen, the system will first ask you to enter screen attributes. Enter a short description of the screen, select screen type Normal, and enter the number of the subsequent screen.

If you enter 0 for the subsequent screen, the system first processes the screen completely and then returns to processing at the point where the screen was called.

Caution: As zero is the initial value of the field; it is hidden when the screen attributes are displayed.

If the user chooses a pushbutton, the runtime system copies the assigned function code to a special screen field (of the OK type). This screen field is typically called the ok_code.

The content of this special screen field is automatically transported if there is a data object of the same name within the program. Following that, PAI processing is triggered, where you find out about the user action through the function code transferred to the program and carry out appropriate processing.

The following sections tell you how to define pushbuttons that use the special screen field of the 'ok' type, declare a data object of the same name within the program, and react to the respective user action.

The special screen field with which the respective function code is transported to the program is called the command field and is available on the screen by default. To use it, you must enter a name for it. Normally, the name OK_CODE is used.|

You declare the program-internal data object with the same name by assigning the type to the system field sy-ucomm (see above graphic).

The dialog transaction is used to trigger screen processing. This includes the following steps (that are executed automatically):

PBO processing
In preparation for the screen display, the PBO modules listed in the PBO block are processed successively.

Field transport from the program to the screen
After PBO has been completed, the data to be displayed is transported to the screen fields.

Screen display
The screen that has been assigned values is sent to the presentation server (SAPGui) and shown to the user.

Field transport from the screen to the program
Each user action on the screen triggers the transport of the screen field contents back to the program.

PAI processing
As a reaction to the user action, the modules listed in PAI are processed successively.

Modules are source code blocks without interface. They are enclosed by the ABAP statements MODULE and ENDMODULE. For each subfunction in PBO or PAI, a corresponding module should be implemented.

Caution: The flow logic of the screen (PBO/PAI) only contains references to modules, which are implemented in the program and consist of ABAP statements. ABAP source code may not be stored directly in the flow logic.

Usually, the module with the main processing in PAI is called USER_COMMAND_nnnn, whereby nnnn represents the screen number.

There are two ways to create a module:

Using forward navigation from the flow logic
Starting from the flow logic of your screen, you can double-click the module reference to create the corresponding module

Using the navigation area of the Object Navigator
You can also create a module from the object list of your program. To do so, use the context menu of the program. In this case, note that you have to include a corresponding reference to the newly created module in the flow logic of your screen.

A module can be called from the flow logic of several screens (reusability).

Please note that modules starting with MODULE ... OUTPUT are PBO modules and can only be called by the PBO of a screen. Accordingly, PAI modules starting with MODULE ... INPUT can only be called by PAI.

If a screen is assigned its own screen number as the next screen, it is processed again after it is closed.

If you enter the screen attribute “next screen =0”, the system first processes the entires on your screen and then returns to processing at the point where the screen call is set.

You can use the ABAP statement SET SCREEN from a module (typically a PAI module) to dynamically overwrite the default next screen specified in the screen attributes (see above graphic). This option can be used for implementing the following SAP standard: When you choose Enter you return to the same screen; only certain pushbuttons take you to other screens. For your screen, enter its own screen number as the next screen (default next screen) and branch to other screens (using the SET SCREENcommand) from PAI only if certain pushbuttons are pressed. (By default, the Enter button does not insert a function code into the command field of the screen). Hence, the initial value of the field (Space) is transported to the program as the function code.

Note that, if the system processes the same screen again, it also runs through all the PBO modules again. If you decide to fill the TABLES structure in a PBO module, you must make sure that data changes made by the user are not overwritten on the screen if the module gets called twice.

For our scenario, one pushbutton should be caught on the first screen and two on the second:

• If you choose Continue (function code GO here) on the first screen, the next screen is set dynamically to 200 in order to get to the second screen.
• If you choose Back (function code BACK here) on the second screen, the next screen is set dynamically to 100 in order to return to the first screen.
• If you choose Exit (function code EXIT ), the next screen is automatically set to zero to return to the call point of the screen. In our case, this means that the dialog transaction is terminated.

Screens, Creating Input/Output Fields

In the second step, input/output fields are to be created on both screens. The first screen should contain the fields Airline and Flight Number as ready-for-input fields. The second screen should contain only display fields. In addition to the Airline and Flight Number fields, it should also include the fields Departure Airport, Destination Airport, Departure Time and Arrival Time.

You have two options for implementing the assignment of field attributes when you create screen fields:

Get from Dictionary:
When you create a screen field, you can copy the type as well as the field attributes of a Dictionary field. This makes all the information about the object available to you, including semantic information about the corresponding data element and foreign key dependencies. The field name is also copied from the ABAP Dictionary.

Get from program:
You can copy the field attributes of a program-internal data object for a screen field. To do so, a generated version of the program must be available (is automatically generated at the time of activation). The name of the data object is used as the field name.

The Graphical Layout Editor offers you easy options for defining further screen elements such as texts, frames, radio buttons, and checkboxes, for example. First, click on the required screen element in the tool bar to select it and then position it in the screen maintenance area.

You can delete screen elements by selecting them with the mouse and then choosing Delete.

You can move screen elements by holding down the left mouse button and dragging them to a new position.

Double-click a screen element to maintain its attributes. Its attributes are displayed in an additional window for maintenance. (Instead of double-clicking, you can also select the element and then choose the Attributes pushbutton.)

To make input mandatory, assign the attribute Required to a screen field. At runtime, the field will be marked accordingly if it is blank. If the user does not fill out the field, an error dialog will follow any user action. After this dialog, the input fields are ready for input again.

Data Transports Between the Program and the Screen

After the second realization level, it is possible to select a flight connection on the first screen and navigate to the second screen. However, only the Airline and Flight Number screen fields contain a value there. This is because they have exactly the same name as the input fields on the first screen. In the second level, the data transport must now be programmed, both from the (first) screen to the program and from the program to the second screen. This enables the user entries to be processed in the program and relevant detail information to be displayed on the second screen.

The TABLES statement is used to define a structure variable of the same type and name with reference to the specified Dictionary structure (for example, a transparent table) within the program. This structure variable then serves as the interface between the program and the screen.

If the screen fields and the TABLES statement refer to the same structured type, then the data in their fields is automatically exchanged on the basis of the fields having the same names. After PBO, from the TABLES structure to the screen fields, and before PAI in the opposite direction.

A special structure is normally created in the ABAP Dictionary that contains the fields that are to be displayed on the screens of an application. This structure can also contain the fields of several database tables. On the screen, fields are defined with a reference to this structure and an interface structure is implemented within the program using the corresponding TABLES statement. This way, you still have a clear interface structure for the data exchange between program and screen, in spite of having fields from different tables.

After processing the PBO event and immediately before sending a screen to the presentation server, the field contents of the TABLES structure within the program are automatically copied to the screen fields with the same names. The moment of this automatic data transport makes sense as the data for the screen display in the TABLES structure is often prepared in PBO.

For user actions on the screen, the contents of the screen fields are transported into TABLES structure fields with the same names before the PAI event is processed. The time of this automatic data transport makes sense, as the user entries are supposed to be processed further in PAI and thus have to be available in the program at that time.

In our example program, the process and data transport looks like this:

1. With a user action on screen 100, the user entries are automatically transported to the TABLES structure BC400_S_DYNCONN within the program.
2. After this, the PAI module USER_COMMAND_0100 is processed.
3. Depending on the function code, a function module for data retrieval is called in the PAI module. The user entries from the TABLES structure are transferred to the function module in the process. The data to be displayed on screen 200 is then placed in the same TABLES structure.
4. After PAI for screen 100, the system navigates to screen 200.
5. After PBO for the second screen, the data is automatically transported from the TABLES structure to the screen fields.

The function code is evaluated in the PAI module USER_COMMAND_0100. If the user chooses the Continue pushbutton (function code GO), a function module for data retrieval is called.

The user entries from the TABLES structure are transferred to the function module. To separate the interface to the screen and the interface to the function module clearly from one another, the data is not transferred directly from the TABLES structure to the function module. It is first copied to the data object that serves as the interface to the function module (global, structured data object gs_connection, type BC400_S_CONNECTION).

If data was retrieved successfully, the result is copied back to the TABLES structure and navigation to the display screen is triggered. If the function module terminates with an exception, a corresponding error message is sent. This error message is displayed directly on screen 100.