If you have attended a recent training class or SAP demonstration where
SAP's "flight model" was used as a database, you should recognize the
abbreviations AA, AZ, and so on, shown on the flight information screen
in Figure 1. But compared to classical training examples, the screen
in Figure 1 is much fancier. The upper left portion shows an airplane
graphic that has no functionality - it is for visual purposes only. On
the lower left is a tree structure, from which users can select carriers
or flight connections from SAP's flight model. The third pane displays
the Web site of the selected carrier or the detail lists for flight connections.
This is just one example of the kinds of easy-to-use,
easy-to-navigate interfaces that you can provide users when you combine
the strengths of GUI control technology with ABAP Objects.
In this article, we show you how to use controls
with ABAP Objects to program single-screen user interfaces. After providing
an overview of the control framework, we will take you step by step through
the development process and provide some sample code - which will run
in R/3 Release 4.6 - that you can use as a starting point for creating
more inviting user interfaces in your own applications.
||User Interface of the Flight Model Program
Control Technology Overview
The R/3 system communicates with the user via screens on the frontend.
In classical ABAP programming, screens may contain input/output fields,
checkboxes, radio buttons, and push buttons to interact with the user.
All user actions that raise the runtime event
PAI (Process After Input) and the respective processing on the application
server are connected to a function code that is transported to the application
Controls in General
Controls are independent software components that are shipped with the
SAP GUI, beginning with Release 4.5. You can place controls on screens
to either replace or work alongside classical components - both are supported
in parallel. SAP currently supports ActiveX controls for Microsoft Windows
platforms and JavaBeans for the SAP GUI in the Java environment.
Note that controls provide a great deal of
functionality and can keep a lot of data at the presentation server without
putting weight on the application server (for example, during scrolling
and editing of texts). On the other hand, frequent data exchange between
the frontend and backend may increase the network load. Therefore, controls
are appropriate when most of the work can be done at the frontend and
when exchange with the backend does not occur too often.
In order to facilitate programming with controls, starting with Release
4.6, the SAP Basis system provides a control framework (CFW). The CFW
encapsulates all available controls in global classes of ABAP Objects.
To work with controls on your screen, simply create objects of these global
classes, call their methods, and react on their events. Since the CFW
classes are part of an inheritance hierarchy, these classes provide a
standardized interface for most of the common functionality you will find
in the controls.
The CFW distinguishes between container controls and application
controls. Application controls are the components you want to use
on the screen. Container controls provide a software layer that standardizes
all layout-related issues and the implementation of application controls.
All application controls must be linked to a container control while the
container control is linked to an area of the screen (see Figure 2).
||Container Controls and Application Controls on Screens
Container controls provide areas on the screen that can be used for
application controls. The most important container controls are encapsulated
in the following global classes²:
- CL_GUI_CUSTOM_CONTAINER: When
you create an object of this class, you must link it to a custom control
on a screen via the IMPORTING parameter container_name
of its constructor. You can use the Screen Painter to create one or
several custom controls within the area of one screen, and you can use
custom controls together with classical screen elements. Any application
control that you link to a custom container will appear within its screen
When you create an object of this class, you must link it to one of
the four edges of a screen. By doing so, you create a new area docked
to a screen without using the Screen Painter. Any application control
that you link to a docking container will appear within that screen
When you create an object of this class, you must link it to an already
existing container control. By doing so, you split the area of the existing
control either vertically or horizontally into two new areas, as was
done to create the screen in Figure 1. You can then link application
controls to the new areas. You can also nest splitter controls to create
After creating objects of container controls, you can create objects
of application controls - the components you want to use onscreen. You
must link each application control to an object of a container control.
You can do this by simply passing the respective reference to the parameter
parent of the application control's constructor. Important application
controls and their respective global classes are:
This control allows you to display interactive lists. (ALV stands for
ABAP List Viewer, which replaces classical list processing.)
- CL_GUI_HTML_VIEWER: This
control allows you to display HTML documents. For example, the new help
viewer of the ABAP keyword documentation uses an HTML control.
- CL_GUI_PICTURE: This
control allows you to display any given picture on an R/3 screen. For
example, the airplane in Figure 1 is displayed in a picture control.
SAP Easy Access is another example of a picture control as background.
This control allows you to display and work with a tree structure. In
addition to the simple tree, there are also other kinds of trees available.
For example, the Object Navigator of the ABAP Workbench uses a tree
- CL_GUI_TEXTEDIT: This
control implements a full-fledged editor for viewing and maintaining
texts. For example, the ABAP Editor uses a textedit control.
You use the methods defined in the control's classes to work with the
controls displayed on the screen. In general, you work with the methods
of the application controls. You would use these, for example, to fill
text from an internal table into the text editor of the textedit control.
But sometimes you will also call methods of the CFW. In order to minimize
the network load between backend and frontend, method calls are buffered
in an automation queue before being sent to the frontend at defined synchronization
points, such as at the end of PBO (Process Before Output) processing.
To force a synchronization point in your program, you can call the static
method cl_gui_cfw=> flush.
Control Events and Event Handling
User actions on controls can trigger events. However, the events of
controls are not classical screen events, which trigger the PAI processing
at the application server and send a function code. Instead, they are
declared as ABAP Objects events in their global wrapper classes. For performance
reasons, a user action on controls is not automatically passed back to
the application server. If you want an event to be passed back to the
application server, you must register it in your program using the special
method set_registered_events, which is available in all application
controls. You can specify two kinds of event handling:
- System Events (default): The event is
passed to the application server, but does not trigger the PAI event
(see Figure 3). In order to react on the event, you must register
an event handler method in your ABAP program with the SET HANDLER
statement. This method is then executed on the application server.
Pros and cons: The benefits of using this default technique is
that the event handler method is executed automatically. There also
are no conflicts with the classical automatic input checks associated
with the screen. The disadvantage is that the contents of the classical
screen fields that might exist alongside controls are not automatically
transported to the program.
If you work with classical screen fields and you really need
to transport their contents during control event handling, you
can call the static method cl_gui_cfw=>set_new_ok_code
to set a function code and trigger the PAI event, including
a field transport. After PAI has been processed, the PBO event
of the next screen is triggered (see Figure 3).
||Handling of System Events
Application Events: With this second type
of event handling, the event is passed to the application server and
triggers the PAI (see Figure 4). If you want to handle the event,
you must include a method call for cl_gui_cfw=>dispatch in
an appropriate PAI dialog module. The dispatch method calls
all event handler methods that are defined and registered with the SET
HANDLER statement for that event. After the event handler has been
processed, control returns to the PAI module and PAI processing continues.
Pros and cons: The advantage of using this method is that you
can specify the point at which the event is handled. The contents of
the screen fields are also transported to the application server beforehand.
The disadvantage is that this kind of event handling can lead to conflicts
with the automatic input checks on the screen, which can cause events
to be lost.
Why two types of event handling? You have these options because controls
may be displayed on classical ABAP screens, and there may be classical
screen elements alongside controls. The flexibility of the two types
of event registration and the methods of the CFW, mentioned above, allow
you to steer the sequence of data transports between frontend and backend.
If you do not use any classical screen components at all, you can simply
work with system events (the default mode).
||Handling of Application Events
Introduction to the Demonstration Program
Our demonstration program is designed to be as simple as possible. It
is meant to demonstrate the basic concepts of programming with GUI controls.
Because of this, we omitted all superfluous code, and we did not exploit
all the possibilities that control technology provides. With the information
we provide in this article, you can go on to modify the program to learn
more. You can find the code in our example at DEMO_ABAP_ OBJECTS_SPLIT_SCREEN
in R/3 Release 4.6C or higher.
Figure 5 shows the processing blocks of the demonstration program.
The program contains two local classes, screen_init and screen_handler,
which are used to create and fill the controls and to react on the user's
input. Since controls are displayed on classical ABAP screens, we need
a small classical framework to call a carrier screen for our controls.
We use the event block LOAD-OF-PROGRAM and two dialog modules
for that purpose.
Listing 1 shows the coding structure
of the program. For our demonstration program, we have chosen the program
type 1 (executable). Note that we could have taken one of the other program
types that support screens, namely a module pool or a function pool. Choosing
an executable just simplifies the program execution, because you can start
the program directly from the ABAP Editor.
The program does not contain any global data declarations, and it does
not make use of the classical reporting events such as START-OF-SELECTION.
It is simply a container for the three processing blocks of the classical
screen framework, shown in Figure 5, and our two local classes.
||Structure of the Demonstration Program