http://help.sap.com/saphelp_nw73/helpdata/en/4d/896df2d3ea5767e10000000a42189e/content.

ht
m
http://sapinsider.wispubs.com/Assets/Articles/2000/June/ABAP-Objects-In-Action-ScreenProgramming-With-The-Control-Framework
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 server.

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

Control Framework
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 our 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 we want to use on the screen. Container controls provide a software layer that standardizes all layoutrelated 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).

Figure 2

Container Controls and Application Controls on Screens

Container Controls
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 area.

CL_GUI_DIALOGBOX_CONTAINER: The dialog box container allows controls to be displayed in an modal

dialog box or full screen.

CL_GUI_DOCKING_CONTAINER: 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 area.

CL_GUI_SPLITTER_CONTAINER: 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 more areas.
CL_GUI_EASY_SPLITTER_CONTAINER: Similar to splitter container, but offers reduced functionality.

Application Controls
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:
CL_GUI_ALV_GRID: 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.

CL_GUI_SIMPLE_TREE: 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 control.

CL_GUI_TEXTEDIT: This control implements a full-fledged editor for viewing and maintaining texts. For
example, the ABAP Editor uses a textedit control.

Control Methods
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 are that the event handler method is executed
automatically (as we dont call event handler method using CALL METHOD statement). 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.
TIP: 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).

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.

NOTE The communication between frontend and backend is handled by the CFW. The frontend-tobackend communication is triggered by events, and the backend-to-frontend communication is triggered by
flushes.
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).

Figure 4
System events:

Handling of Application Events

A system event is triggered before any automatic field checks (e.g., required fields) have taken place on the
screen, and before any field transports.
For system events the flow-logic of the screen is not executed. That means that the PAI and PBO modules
are not processed.
In the events table the field appl_event must be set to SAPCE:
The event is passed to the application server, but does not trigger the PAI.
It will execute an event handler method in ABAP program for the event (using the SET HANDLER
statement), on the application server.
Within the event handler method, the static method SET_NEW_OK_CODE of the global class CL_GUI_CFW
is used to set a function code and trigger the PAI event.
After the PAI has been processed, the PBO event of the next screen is triggered.
Application events:
An application event triggers the normal PAI event. Consequently, all field checks and field transports have
taken place.
If you want the event handler method to be called at a particular point in your application program, you must
call the static method CL_GUI_CFW=>DISPATCH in a PAI module.
If there is also an event handler method defined in ABAP program for the event (using the SET HANDLER
statement), the DISPATCH method calls it. After the event handler has been processed, control returns to the
PAI event after the DISPATCH statement and PAI processing continues.
The advantage of this is that you can specify yourself the point at which the event is handled
Problem: you need to have a PAI/PBO event after user performs an action on your screen (e.g. clicks a toolbar button).
Solution: to invoke PAI event (and therfore PBO too) you have to emulate a user command in your program.
You can achieve this using below two lines of code.
* invoke PAI/PBO events to refresh the screen status
cl_gui_cfw=>set_new_ok_code( new_code = 'DUMMY' ).
cl_gui_cfw=>flush( ).

DUMMY is to avoid executing any action assigned for the user command, but if you want you can put there a handled user code and
this will invoke a desired action.
CASE sy-ucomm.
WHEN 'DELETE'.
" do some action - possibly delete something
WHEN OTHERS.
" do nothing
ENDCASE.

* invoke PAI/PBO events to refresh the screen status and do nothing

cl_gui_cfw=>set_new_ok_code( new_code = 'DUMMY' ).
cl_gui_cfw=>flush( ).
* invoke PAI/PBO events to refresh the screen status and delete something
cl_gui_cfw=>set_new_ok_code( new_code = 'DELETE' ).
cl_gui_cfw=>flush( ).

PTRS:
1. Always register event handler after creating the alv grid object and before calling
the method set_tabl_for_first_display.
CREATE OBJECT go_alv
EXPORTING
i_parent = go_container.

SET HANDLER go_event->handle_toolbar FOR go_alv.

CALL METHOD go_alv->set_table_for_first_display
EXPORTING
i_structure_name
= 'SKAT'
is_layout
=

CHANGING
it_outtab

= lt_data.

2. Call following in PAI Event

call method cl_gui_cfw=>dispatch.
CASE OK_CODE.
WHEN 'EXIT'.
PERFORM EXIT_PROGRAM.
WHEN OTHERS.
*
do nothing
ENDCASE.
3. To get the cursor in ALV grid, use following after alv_displayed.
CALL METHOD cl_gui_control=>set_focus
EXPORTING
control = go_alv.