When ’back’.

SET SCREEN 0. WHEN ’SAVE’.

^{MOVE-CORRESPONDING sdyn_book TO wa_sbook.}

MESSAGE i060(bc400). SET SCREEN 0.

^ENDCASE.

ENDMODULE. " USER_COMMAND_0100 INPUT

Flow logic for screen 100:

PROCESS BEFORE OUTPUT.

MODULE clear_ok_code.

PROCESS AFTER INPUT.

MODULE user_command_100.

^{Lesson Summary}

^{You should now be able to:}

• List attributes and benefits of screens

• Implement a simple screen with input and output fields as well as pushbuttons and call it from your program

• Explain and implement the program-internal processing for screen calls

Lesson:

292

User Interface

Lesson Duration: 70 Minutes

Lesson Overview

In this lesson, you will assign a title to your list and your screen. Furthermore, you will create a status for the list (with standard list functions) as well as a status for the screen that refers to the components of the list status.

Lesson Objectives

After completing this lesson, you will be able to:

• Implement a GUI title

• Implement a GUI status (menu bar, symbol toolbar and application toolbar)

for the list and screen

_{• Maintain the function key assignment of the screen}

This lesson is based closely on the example in the demo. However, at the end of the lesson, the relevant exercise should follow.

Business Example

You need to provide user interfaces (title and status) for your program screens.

User interface

Figure 182: GUI Title and GUI status of a Screen (Overview)

The user interface of a screen consists of the following elements:

• The title bar contains the title of the current screen (GUI title).

• The menu bar contains expandable menus, which have corresponding program functions as menu entries and/or submenus (cascading menus).

The System and Help menus can be found on every screen in the SAP system and always contain the same functions. Neither of these menus can be changed or hidden.

On every screen in the SAP system, the standard toolbar always contains the same standard pushbuttons for functions that are used frequently. The pushbuttons for functions that cannot be executed on the current screen are grayed out.

The function key assignment of a screen can be displayed by right-clicking. Ideally, you should be able to execute all menu functions using a function key as well as from the menu entries.

In the application toolbar, frequently used functions of the screen are made available.

Together, menu bar, standard toolbar, function key assignment, and application toolbar make up the GUI status.

To use the GUI title or GUI status on a screen, these must be assigned to the screen. This happens by means of the ABAP statements SET TITLEBAR and SET PF-STATUS.

Figure 183: Implementing the GUI Title

There are two options for implementing a GUI title for your screen:

• You first create the GUI title via the context menu on the object list for your program and then assign it to the appropriate screen using the SET TITLEBAR statement.

• You create the GUI title by means of forward navigation from the respective

SET TITLEBAR statement of your program (see graphic above). A title can have a maximum of 20 characters.

After assigning a GUI title to a screen this is inherited to all subsequent screens. If you want to have a different title for each of the subsequent screens, then you have to set a separate title for each screen.

Figure 184: User Interface for the Example Program (Objective)

The user interface of the example program is to have the following properties:

• The same menu bar appears on the list and the screen. But the executable functions are only displayed as selectable (black) for the current screen. Functions that do not make sense for the current screen and cannot be executed are displayed as non-selectable (gray).

• In the toolbar, only those pushbuttons appear as selectable (in color) which make sense for the current screen. All others are displayed as non-selectable (grey).

The objective is to implement a consistent interface for the entire program.

Figure 185: Status Inheritance to Subsequent Screens

After assigning a GUI status to a screen this is inherited to all subsequent screens. If you want to have a different status for each of the subsequent screens, then you have to set a separate title for each screen. The following graphic illustrates this:

Figure 186: Setting a Status for Each Screen

Figure 187: Reusability of Already Defined Subobjects by means of

Referencing

For simple maintenance, we will not create the subobjects menu bar, application toolbar, and toolbar with function key assignment again when we maintain the screen status. Instead we will refer to the corresponding subobjects of the already created list status. Of course, we will still have to decide the definition of each single status and which functions make sense for the corresponding screen and have to be set up as selectable (active).

Figure 188: Implementing the GUI Status for the List

For the implementation of a status for the screen you have the same two options as for the implementation of a GUI title:

• First, create the GUI status using the object list of the program and then assign it to the screen using the SET PF-STATUS statement or

• Create the GUI status by means of forward navigation from the corresponding SET PF-STATUS statement of your program.

Choose the status type “dialog status” that has been designed for the status of normal screens.

Status names can have a maximum of 20 characters.

The tool for the status maintenance is called Menu Painter.

Hint: If you choose the STATUS_nnnn name suggested in the screen flow logic for your PBO module and create the PBO module from there by means of forward navigation, then the two statements

SET PF-STATUS and SET TITLEBAR

are automatically generated as a comment in the module. You can then remove the comment asterisks, enter the title and status descriptions, and create the title and status by means of forward navigation.

Figure 189: Including the Template

In order to load an available status (standard status for list or selection screen, status of another program) to your status as a template, you can use the menu Extras → Adjust Template in the Menu Painter. With this function, you can load the subobjects of any status to the current status.

Figure 190: Maintaining the Menu Bar in the Menu Painter

If so desired, the system will suggest standard values for your menu bar, which you can overwrite.

The menu bar can contain up to eight menus: You can define up to six of these yourself, the System and Help menus are standard and are added automatically by the system.

Figure 191: Maintaining the Function Key Assignment in the Menu Painter

Function key assignment is split into three areas:

Standard Toolbar

The buttons of the standard toolbar are linked to fixed corresponding function key (or combinations of function keys). For example, the pushbutton with the disk symbol is linked to the key combination Ctrl+S. This means

that functions that are assigned to the buttons of the standard toolbar by specifying the corresponding function code can also be triggered using the corresponding function key (combinations).

Recommended Function Key Settings

The system proposes the functions that you should generally assign to specific function keys. The user is accustomed to this assignment. Hence, you should not change them without a good reason.

Freely Assigned Function Keys

All other function key (combinations) that are freely assigned with function codes are listed.

You can also define buttons on an application toolbar for frequently used function keys. These pushbuttons can have icons or text or both.

Do not confuse the pushbuttons of the application tool bar with those that you can implement using the Layout Editor on the screen. Nonetheless, pushbuttons and function keys as well as the menu entries of a status have the same effect as pushbuttons that are placed directly on the screen. They enter their function code in the command field of the screen and trigger the field transport to the program as well as PAI processing. The functions of the list status that you have defined

yourself are an exception as they trigger the ABAP event AT USER-COMMAND, whereby the corresponding function code is transferred to the system field

sy-ucomm. For more information, refer to the keyword documentation for “AT USER-COMMAND” or course BC405 (list programming).

Figure 192: Referencing to Subobjects of an Available Status

You can use the icon depicted in the above graphic (or the F4 key) to display all subobjects (menu bars, function key assignments or application toolbars) that have already been defined for the program. When a subobject is selected, a reference is made to it. This means that you use the same subject in the local status. However, all functions of the subobject for the local status are automatically set to inactive (non-selectable). Functions that do make sense in the local status and are set up as selectable must now be activated. The following graphic illustrates this:

Figure 193: Setting Functions to Active or Inactive in the Status

You can use the pushbutton depicted in the graphic to also set functions to inactive. In our example, we reference the subobjects of the list status when we define the

screen status. In the screen status, if we add the new function code SAVE to the toolbar and the Flight data menu, then the system will tell us that the current status refers to the menu bar and toolbar of the list status and that a change is made to the original. If we confirm the dialog box, then the function code is added

to the menu bar or application toolbar of the list status. There, however, it is displayed as inactive.