ABAP Objects in Action - Google Sites

Horst Keller and Gisbert Loff

ABAP Objects in Action Screen Programming with the Control Framework In the preceding two issues of the SAP Technical Journal we presented ABAP Objects in a more theoretical way. After a general introduction to ABAP Objects in Number 3 we discussed the concepts of inheritance, interfaces and polymorphism in depth in Number 4. Now you might say: 'That's nice but what can I do with ABAP Objects and does it touch my daily ABAP live at all?' The answer is definitely 'Yes!' and in this article, we will give you one of several explanations why: We will show you how to program screens that include controls with ABAP Objects by presenting a demonstration program with a single screen user interface as shown in Figure 1.

Figure 1 User interface of the demonstration program. The screen is split in three parts. The upper left part shows a picture of an airplane. This picture has no function but is purely for decoration purposes. Of course you might change that after reading the article! The lower left part contains a tree-like structure, where the user can select carriers or flight connections from SAP's flight model which you know from demonstrations or training. The large area on the right side can alternatively show the Web site of the selected carrier or detail lists for flight connections. Figure 1 shows the situation after selecting node 'UA'.

1

In R/3 Release 4.6 or higher you will find a lot of screens that are designed with the control technology, as for example the object browser of the ABAP Development Workbench. The usage of control technology on screens is an important part of the Enjoy SAP initiative to enhance the usability of the system for the end users. In the following we will give you a short introduction to the Controls Technology and take you then on a detailed walk through the demonstration program, where you will learn how to use ABAP Objects to design such enjoyable screens.

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. Controls are independent software components that from Release 4.5 on are shipped with the SAP GUI. You can place controls on screens instead or besides the classical components. In the moment, SAP supports ActiveX controls for MS Windows platforms and JavaBeans for the SAP GUI in the Java environment. Controls have the advantage, that they provide a lot of functionality and can keep a lot of data at the presentation server without putting weight on the application server, as for example during scrolling and editing of texts. This means on the other hand, that a frequent data exchange between frontend and application backend may increase the network load. Therefore, controls are appropriate, when most of the work can be done at the frontend and exchange with the backend does not occur too often. Control Frame Work. In order to facilitate programming with controls, from R/3 Release 4.6 on the SAP Basis system provides the so called Control Framework (CFW). The CFW encapsulates all available controls in global classes of ABAP Objects. In order to work with controls on your screens, you simply have to create objects of that global classes, call their methods and react on their events. Since the CFW classes are part of an inheritance tree, you will find standardized interfaces for most of the common functionality provided by the controls. The CFW distinguishes between application controls and container controls. The 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).

2

Screen

Docking Container

Custom Control Custom Container Application Control Splitter Container Application Control

Docking Container Application Control Figure 2 Container controls and application controls on screens. Container Controls. Container controls provide areas on the screen, which can be used for application controls. Important container controls are encapsulated in the following classes: •

• •

CL_GUI_CUSTOM_CONTAINER: When you create an object of that class, you must link it to a so called Custom Control on a screen via the IMPORTING parameter CONTAINER_NAME of its constructor. A Custom Control is simply an area of a screen that you create and name with the Screen Painter. You can create 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_DOCKING_CONTAINER: When you create an object of that 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 that 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. You can then link application controls to the new areas. You can also nest splitter controls to create more areas.

Application Controls. After creating objects of container controls, you can create objects of application controls. You must link each application control to an object of a container control by simply passing the respective reference to the parameter PARENT of the application control's constructor. Important application controls and the respective public classes are: • • • • •

CL_GUI_ALV_GRID: This control allows you to display interactive lists. ALV stands for ABAP List Viewer and is going to replace the classical list processing. CL_GUI_HTML_VIEWER: This controls 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 arbitrary pictures on a R/3 screen. For example, the SAP Easy Access uses a picture control as background. CL_GUI_SIMPLE_TREE: This control allows you to display and work with a treelike structure. Besides 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 fully fledged editor for viewing and maintaining texts. For

3

example, the ABAP Editor uses a Textedit control. Note that the global classes follow a naming convention: The prefix CL denotes a global class and the prefix GUI shows that the classes are part of the CFW and inherit from the same superclasses. 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, for example to fill text from an internal table into the text editor of the Textedit control. But sometimes you will call also methods of the CFW. In order to minimize the network load between backend and frontend, method calls are buffered in a so called Automation Queue before being sent to the frontend at defined synchronization points, as for example at the end of PBO processing. You can always force a synchronization point in your program by calling the static method CL_GUI_CFW=>FLUSH. Control Events. User actions on controls can trigger events. The events of controls are not the classical screen events, which trigger the PAI processing at the application server and send a function code, but they are declared as ABAP Objects events in their global wrapper classes. For performance reasons, an 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 that 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. Then this method is executed on the application server. The advantage of using this technique is that the event handler method is executed automatically and there 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 besides 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).

System Event

Control Screen

Event EventHandler Handler Method Method

PAI PAIModule Module

SET_NEW_OK_CODE SET_NEW_OK_CODE

ABAP Program Figure 3 Handling of system events.

4

PBO PBOModule Module

•

Application Events: 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. The advantage is that you can specify yourself the point at which the event is handled, and the contents of the screen fields are 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, causing events to be lost.

5

Application Event

Control Screen

PAI PAI Module Module

Event EventHandler Handler Method Method

PBO PBOModule Module

DISPATCH DISPATCH

ABAP Program Figure 4 Handling of application events. The two kinds of event handling and the possibility to choose between them reflects the fact that controls are displayed on classical ABAP screens and that there might be classical screen elements besides controls. The two kinds of event registration and the above mentioned methods of the CFW enable 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.

Introduction to the Demonstration Program Our demonstration program is written as simple as possible. Its purpose is to demonstrate the concepts of programming with GUI controls. Therefore, we omitted any lines of superfluous code and we didn't exploit all possibilities that are provided by the used controls. After reading the article, you can go on and modify the demonstration program to learn more. You find the code for the example in DEMO_ABAP_OBJECTS_SPLIT_SCREEN in R/3 Release 4.6C or higher. Program structure. Figure 5 shows the processing blocks of the demonstration program.

6

Class ClassSCREEN_INIT SCREEN_INIT

Class ClassSCREEN_HANDLER SCREEN_HANDLER

Methods Methods

Classical Classical Processing ProcessingBlocks Blocks Event EventBlocks Blocks

Methods Methods

CONSTRUCTOR CONSTRUCTOR

CONSTRUCTOR CONSTRUCTOR

INIT_SCREEN INIT_SCREEN

HANDLE_NODE_ HANDLE_NODE_ DOUBLE_CLICK DOUBLE_CLICK

FILL_TREE FILL_TREE

FILL_HTML FILL_HTML

MODULE MODULE......PBO PBO

FILL_PICTURE FILL_PICTURE

FILL_LIST FILL_LIST

MODULE MODULE......PAI PAI

LOAD-OF-PROGRAM LOAD-OF-PROGRAM

Dialog DialogModules Modules

DEMO_ABAP_OBJECTS_SPLIT_SCREEN Figure 5 Structure 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 LOADOF-PROGRAM and two dialog modules for that purpose. Listing 1 shows the respective coding structure of the program. PROGRAM demo_abap_objects_split_screen. * Classes ***************************************************** CLASS screen_init DEFINITION CREATE PRIVATE. ... ENDCLASS. CLASS screen_handler DEFINITION. ... ENDCLASS. CLASS screen_init IMPLEMENTATION. ... ENDCLASS. CLASS screen_handler IMPLEMENTATION. ... ENDCLASS. * Classical processing blocks ********************************** LOAD-OF-PROGRAM. ... MODULE status_0100 OUTPUT. ... ENDMODULE. MODULE cancel INPUT. ...

7

ENDMODULE.

Listing 1 Layout of the demonstration program. We have chosen the program type 1 (executable) for our demonstration program. Note that we could have taken also 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 it 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 as for example START_OF_SELECTION. It is simply a container for our two local classes and the three processing blocks of the classical screen framework.

The program at runtime. Figure 6 shows which objects the program uses during screen display and the references between these objects.

Screen with Controls

CFW ABAP Program

CL_GUI_SPLITTER_CONTAINER

SCREEN_HANDLER CL_GUI_SIMPLE_TREE

CL_GUI_SPLITTER_CONTAINER

CL_GUI_HTML_VIEWER

CL_GUI_PICTURE

CL_GUI_ALV_GRID

Figure 6 Runtime objects of the demonstration program. During screen display, there is no instance of the local class SCREEN_INIT, because there is no global reference variable in the program which can point to such an instance. An object of SCREEN_INIT will be created temporarily during each PBO processing of the screen, where it is used as a factory to create the control objects from the global classes CL_GUI_SPLITTER_CONTAINER, CL_GUI_PICTURE, and

8

CL_GUI_SIMPLE_TREE. After each PBO processing, the object of SCREEN_INIT will be deleted by the garbage collector. The objects of the global classes are kept alive by pointers from the CFW, because they are bound to screen areas. An instance of SCREEN_HANDLER is registered as an event handler for events of object CL_GUI_SIMPLE_TREE. This instance itself holds references to objects of the global classes CL_GUI_HTML_VIEWER and CL_GUI_ALV_GRID. The instances of the global classes are linked to controls on the screen via the CFW layer. The two objects of CL_GUI_SPLITTER_CONTAINER split the screen in three areas. The objects of the application controls are linked to these areas. The objects of CL_GUI_HTML_VIEWER and CL_GUI_ALV_GRID are both linked to the same area.

Demonstration Program in Detail The following sections explain the definitions and the processing blocks of the demonstration program in detail.

Cassical screen frame work. Listing 2 shows the complete coding of the three classical processing blocks. LOAD-OF-PROGRAM. CALL SCREEN 100. MODULE status_0100 OUTPUT. SET PF-STATUS 'SCREEN_100'. SET TITLEBAR 'TIT_100'. CALL METHOD screen_init=>init_screen. ENDMODULE. MODULE cancel INPUT. LEAVE PROGRAM. ENDMODULE.

Listing 2 Classical processing blocks of the demonstration program. The ABAP runtime environment raises the event LOAD_OF_PROGRAM in the moment when the program is started. The respective processing block does nothing but calling Screen 100. Screen 100 is created with the Screen Painter. In its screen flow logic, the two dialog modules STATUS_0100 and CANCEL are called, the latter with the addition AT EXIT-COMMAND. We did not use the Graphical Screen Painter for our example, because we have no classical elements on our screen. The PBO module sets an GUI status. Within that status the three function codes BACK, EXIT and CANCEL are activated with function type E (Exit Command) in the symbol bar. Therefore, the PAI module is called only when the user wants to leave the program. The most important action during PBO is calling the static method INIT_SCREEN of class SCREEN_HANDLER. All actual screen handling is encapsulated in the two local classes.

Local class definitions. Listing 3 shows the declaration parts of the two local classes of the program. CLASS screen_init DEFINITION CREATE PRIVATE. PUBLIC SECTION. CLASS-METHODS init_screen. METHODS constructor. PRIVATE SECTION. DATA: splitter_h TYPE REF TO cl_gui_splitter_container, splitter_v TYPE REF TO cl_gui_splitter_container, picture TYPE REF TO cl_gui_picture, tree TYPE REF TO cl_gui_simple_tree. METHODS: fill_tree, fill_picture. ENDCLASS. CLASS screen_handler DEFINITION. PUBLIC SECTION. METHODS: constructor IMPORTING container

9

TYPE REF TO cl_gui_container, handle_node_double_click FOR EVENT node_double_click OF cl_gui_simple_tree IMPORTING node_key. PRIVATE SECTION. DATA: html_viewer TYPE REF TO cl_gui_html_viewer, list_viewer TYPE REF TO cl_gui_alv_grid. METHODS: fill_html IMPORTING carrid TYPE spfli-carrid, fill_list IMPORTING carrid TYPE spfli-carrid connid TYPE spfli-connid. ENDCLASS.

Listing 3 Declaration parts of the two local classes. Each of the declaration parts contains two visibility sections. Only those class components that must be used from the outside client are declared in the public sections. All other components are encapsulated in the private sections. All attributes are reference variables which refer to global classes of the CFW. Each class has an instance constructor and private methods, that are used to fill the controls with data. Furthermore, class SCREEN_INIT has a public static method INIT_SCREEN that can be called without creating an object of that class and class SCREEN_HANDLER has an event handler method HANDLE_NODE_DOUBLE_CLICK that can handle events of the global class CL_GUI_SIMPLE_TREE. Note the addition CREATE PRIVATE in the definition of SCREEN_INIT. Objects of that class can be created only within the class itself.

Static method INIT_SCREEN. Listing 4 shows the static method INIT_SCREEN of class SCREEN_INIT. METHOD init_screen. DATA screen TYPE REF TO screen_init. CREATE OBJECT screen. ENDMETHOD.

Listing 4 The static method INIT_SCREEN of class SCREEN_INIT. The single purpose of method INIT_SCREEN is to create a temporary object of class SCREEN_INIT. This is done by using a local reference variable SCREEN. During the CREATE OBJECT statement, the instance constructor of SCREEN_INIT is executed. Note that after leaving method INIT_SCREEN, the reference variable SCREEN is deleted. The object is not referenced any more and will be deleted by the next turn of the garbage collector.

Instance constructor of SCREEN_INIT. Listing 5 shows the instance constructor of class SCREEN_INIT. METHOD constructor. DATA: events TYPE cntl_simple_events, event LIKE LINE OF events, event_handler TYPE REF TO screen_handler, container_left TYPE REF TO cl_gui_container, container_right TYPE REF TO cl_gui_container, container_top TYPE REF TO cl_gui_container, container_bottom TYPE REF TO cl_gui_container. CREATE OBJECT splitter_h EXPORTING parent = cl_gui_container=>screen0 rows = 1 columns = 2. CALL METHOD splitter_h->set_border EXPORTING border = cl_gui_cfw=>false. CALL METHOD splitter_h->set_column_mode EXPORTING mode = splitter_h->mode_absolute. CALL METHOD splitter_h->set_column_width EXPORTING id = 1

10

width = 110. container_left = splitter_h->get_container( row = 1 column = 1 ). container_right = splitter_h->get_container( row = 1 column = 2 ). CREATE OBJECT splitter_v EXPORTING parent = container_left rows = 2 columns = 1. CALL METHOD splitter_v->set_border EXPORTING border = cl_gui_cfw=>false. CALL METHOD splitter_v->set_row_mode EXPORTING mode = splitter_v->mode_absolute. CALL METHOD splitter_v->set_row_height EXPORTING id = 1 height = 160. container_top = splitter_v->get_container( row = 1 column = 1 ). container_bottom = splitter_v->get_container( row = 2 column = 1 ). CREATE OBJECT picture EXPORTING parent = container_top. CREATE OBJECT tree EXPORTING parent = container_bottom node_selection_mode = cl_gui_simple_tree=>node_sel_mode_single. CREATE OBJECT event_handler EXPORTING container = container_right. event-eventid = cl_gui_simple_tree=>eventid_node_double_click. event-appl_event = ' '. APPEND event TO events. CALL METHOD tree->set_registered_events EXPORTING events = events. SET HANDLER event_handler->handle_node_double_click FOR tree. CALL METHOD: me->fill_picture, me->fill_tree. ENDMETHOD.

Listing 5 The instance constructor of class SCREEN_INIT. The instance constructor is used to create all the container controls on Screen 100 and two of the application controls. Furthermore it creates an event handler for one of the application controls. Most of the data objects that are needed for that purpose are declared locally within the constructor. The reference variables of type CL_GUI_CONTAINER can contain references that point to any container control at the screen. First, the constructor creates an object of the global class CL_GUI_SPLITTER_CONTAINER using the reference variable SPLITTER_H. In the CREATE statement, actual parameters are passed to the IMPORTING-parameters of the global class' constructor. By passing the static attribute SCREEN0 of class CL_GUI_CFW to the parameter PARENT, we use the entire area of Screen 100 as a Custom Control implicitly. This is why we didn't use the graphical screen painter for Screen 100. But you could also go and create a Custom Control on Screen 100 and pass its name instead of SCREEN0. Then, only this area will be used for displaying the controls. By filling the remaining IMPORTING-parameters with appropriate values, we split Screen 100 into two columns. For each column, a new container control is created. References to each new container are stored in a system table of the CFW. This table is not explicitly visible to the programmer. Nevertheless, it points to container control objects of the program that are currently linked to a screen and prevents them from being deleted by the garbage collector, even if it is not referenced in the program itself (see Figure 6). If you want to remove a control object from the program, you must use its method FREE before initializing all respective

11

reference variables. After setting some attributes of the columns, we read the references to our containers from the CFW into the local reference variables CONTAINER_LEFT and CONTAINER_RIGHT by functional calls of method GET_CONTAINER. After that, we follow the same procedure to split the left column into two rows. Here, we pass the reference in CONTAINER_LEFT to the constructor of CL_GUI_SPLITTER_CONTAINER and get references of the two new container objects into the local reference variables CONTAINER_TOP and CONTAINER_BOTTOM. Now we have already created all container controls that we need and can go on to create our application controls. With the instance constructor of class SCREEN_INIT, we create the two application controls for the containers in the left column. As application controls, we create an object of CL_GUI_PICTURE and an object of CL_GUI_SIMPLE_TREE. We link the objects to container controls by passing the references in CONTAINER_TOP and CONTAINER_BOTTOM to their constructor's IMPORTING parameter PARENT. Since we want our program to react on user actions in the Tree Control, we must provide and register an event handler. To do so, we create an object of our local class SCREEN_HANDLER. The constructor of this class demands an IMPORTING-parameter of type CL_GUI_CONTAINER and we pass the reference to the right column's container control. As explained above, we must use the special method SET_REGISTERED_EVENTS besides the simple SET HANDLER statement in order to register our object of class SCREEN_HANDLER as an event handler for the Tree Control. The parameters are passed via an internal table of type CNTL_SIMPLE_EVENTS, which is defined in the ABAP Dictionary. By moving a blank character (initial value) and not an 'X' to the component APPL_EVENT, we define that the event is handled as a system event (default) and not as an application event. Finally, the constructor calls the methods FILL_PICTURE and FILL_TREE to initialize the contents of our application controls on the screen.

Method FILL_PICTURE. Listing 6 shows the instance method FILL_PICTURE of class SCREEN_INIT. METHOD fill_picture. TYPES pict_line(256) TYPE c. DATA pict_tab TYPE TABLE OF pict_line. DATA url(255) TYPE c. IMPORT pict_tab = pict_tab FROM DATABASE abtree(pi) ID 'FLIGHTS'. CALL FUNCTION 'DP_CREATE_URL' EXPORTING type = 'IMAGE' subtype = 'GIF' TABLES data = pict_tab CHANGING url = url. CALL METHOD picture->load_picture_from_url EXPORTING url = url. CALL METHOD picture->set_display_mode EXPORTING display_mode = picture->display_mode_fit_center. ENDMETHOD.

Listing 6 The instance method FILL_PICTURE of class SCREEN_INIT. The method FILL_PICTURE imports a picture in GIF format from an INDX-type database table ABTREE into a local internal table PICT_TAB. The function module DP_CREATE_URL creates an URL for that internal table and passes it to the local variable URL. By passing that URL to method LOAD_PICTURE_FROM_URL of our picture control object, we send the picture to the control at the screen. The method SET_DISPLAY_MODE allows us to set the attributes of the picture on the screen. Instead of working with an internal table, you can also use a local picture file on your presentation server and pass its name directly to the parameter URL of method LOAD_PICTURE_FROM_URL. Our program has the advantage of working for all users. The question remains, how one can save pictures in an INDX-type database table. Listing 7 shows a little helper routine which fulfills that purpose.

12

REPORT picture_save. PARAMETERS file TYPE rlgrap-filename DEFAULT 'C:\TEMP\.GIF'. PARAMETERS id(20) TYPE c. DATA pict_line(256) TYPE c. DATA pict_tab LIKE TABLE OF pict_line. CALL FUNCTION 'WS_UPLOAD' EXPORTING filename = file filetype = 'BIN' TABLES data_tab = pict_tab. EXPORT pict_tab = pict_tab TO DATABASE abtree(pi) ID id.

Listing 7 Helper routine to save pictures in a database table. Provide your favorite picture in a folder as for example C:\TEMP\ of your presentation server and simply run this little program. The program loads the picture in binary format into an internal table and exports it to an INDX-type database table (We strongly recommend to create your own INDX-type table instead of using ABTREE or INDX itself!)

Method FILL_TREE. Listing 8 shows the instance method FILL_TREE of class SCREEN_INIT. METHOD fill_tree. DATA: node_table TYPE TABLE OF abdemonode, node TYPE abdemonode, spfli_wa TYPE spfli, spfli_tab TYPE SORTED TABLE OF spfli WITH UNIQUE KEY carrid connid. SELECT carrid connid FROM spfli INTO CORRESPONDING FIELDS OF TABLE spfli_tab. node-hidden = ' '. node-disabled = ' '. node-isfolder = 'X'. node-expander = ' '. LOOP AT spfli_tab INTO spfli_wa. AT NEW carrid. node-node_key = spfli_wa-carrid. CLEAR node-relatkey. CLEAR node-relatship. node-text = spfli_wa-carrid. node-n_image = ' '. node-exp_image = ' '. APPEND node TO node_table. ENDAT. AT NEW connid. CONCATENATE spfli_wa-carrid spfli_wa-connid INTO node-node_key. node-relatkey = spfli_wa-carrid. node-relatship = cl_gui_simple_tree=>relat_last_child. node-text = spfli_wa-connid. node-n_image = '@AV@'. node-exp_image = '@AV@'. ENDAT. APPEND node TO node_table. ENDLOOP. CALL METHOD tree->add_nodes EXPORTING table_structure_name = 'ABDEMONODE' node_table = node_table. ENDMETHOD.

13

Listing 8 The instance method FILL_TREE of class SCREEN_INIT. To create a treelike structure within the Tree Control you must call method ADD_NODES and pass an internal table of special structure and contents to that method. In our case, the line type of the internal table NODE_TABLE is ABDEMONODE defined in the ABAP Dictionary. You must create such types by copying the global template structure MTREESNODE. The internal table contains one line for each node of the tree. Each node must have a unique key NODE_KEY. The columns RELATKEY and RELATSHIP describe the relations between the nodes. Besides, you can add description texts, change the standard icons, and so on. In our example, we create a node table from the contents of database table SPFLI. SPFLI is the well known table of flight connections from SAP's training and demonstration flight model. We select all data from SPFLI into the sorted internal table SPFLI_TAB and process this table in a loop. There, we fill the internal table NODE_TABLE with lines that represent a tree structure of two hierarchy levels. The attributes of the nodes are set by assigning flags to some columns of NODE_TABLE. Note that we replace the standard folder icon with an airplane icon for the subnodes by assigning the internal code '@AV@' to the image columns. You find the internal codes of all SAP icons by executing the report SHOWICON.

Instance constructor of SCREEN_HANDLER. Listing 9 shows the instance constructor of class SCREEN_HANDLER. METHOD constructor. CREATE OBJECT: html_viewer EXPORTING parent = container, list_viewer EXPORTING i_parent = container. ENDMETHOD.

Listing 9 The instance constructor of class SCREEN_HANDLER. The instance constructor of class SCREEN_INIT creates an object of class SCREEN_HANDLER. Therefore, the execution of the instance constructor of class SCREEN_HANDLER is embedded in the execution of the instance constructor of class SCREEN_INIT. It creates two application control objects which are both linked to the right column of our vertical splitter control. Remember, that the instance constructor of class SCREEN_INIT passes the reference to the right column's container control to the constructor's parameter CONTAINER in the CREATE OBJECT statement. The application controls can display either HTML pages or lists but they are not filled during the constructor's execution yet. Filling these controls depends on the user's action in the Tree Control.

Method HANDLE_NODE_DOUBLE_CLICK. Listing 10 shows the instance method HANDLE_NODE_DOUBLE_CLICK of class SCREEN_HANDLER. METHOD handle_node_double_click. DATA: carrid TYPE spfli-carrid, connid TYPE spfli-connid. carrid = node_key(2). connid = node_key+2(4). IF connid IS INITIAL. CALL METHOD: fill_html EXPORTING carrid = carrid, html_viewer->set_visible EXPORTING visible = 'X', list_viewer->set_visible EXPORTING visible = ' '. ELSE. CALL METHOD: fill_list EXPORTING carrid = carrid connid = connid, list_viewer->set_visible EXPORTING visible = 'X', html_viewer->set_visible EXPORTING visible = ' '. ENDIF. CALL METHOD cl_gui_cfw=>flush. ENDMETHOD.

14

Listing 10 The instance method HANDLE_NODE_DOUBLE_CLICK of class SCREEN_HANDLER. This method is declared and registered as an event handler for the event NODE_DOUBLE_CLICK of our Tree Control object. Therefore, each mouse double-click on a node of the tree triggers that method. The method imports the event's EXPORTING parameter NODE_KEY which contains the key of the selected node. Depending on the key's contents, the event handler either calls method FILL_HTML or FILL_LIST. Furthermore, it sets the visibility of the two application controls referenced by HTML_VIEWER and LIST_VIEWER. Remember that both controls are linked to the same container at the screen. The event handler steers their alternative display in that container. As stated above, method calls to the frontend are buffered in an automation queue. There is no automatic synchronization point after handling a system event on the backend. Therefore, we must force the system to process the preceding method calls by calling the static method CL_GUI_CFW=>FLUSH. Note that we do not have any regular PAI processing in our program except when the user leaves the screen. The communication between frontend and backend is handled by the CFW. The frontend to backend communication is triggered by events and the backend to frontend communication is triggered by flushes.

Method FILL_HTML. Listing 12 shows the instance method FILL_HTML of class SCREEN_HANDLER. METHOD fill_html. DATA url TYPE scarr-url. SELECT SINGLE url FROM scarr INTO url WHERE carrid = carrid. CALL METHOD html_viewer->show_url EXPORTING url = url. ENDMETHOD.

Listing 12 The instance method FILL_HTML of class SCREEN_HANDLER. This method reads the value of column URL from the database table SCARR according to the node the user has selected by double-click. From release 4.6C on, the new column URL of the carrier database table SCARR contains the addresses of the carrier's Web sites. If you don't find that data in your system or the addresses have changed in the meantime, you might provide your own data and change the program accordingly. The selected URL is simply passed to the method SHOW_URL of our HTML control which displays it in its area on the screen.

Method FILL_LIST. Listing 13 shows the instance method FILL_LIST of class SCREEN_HANDLER. METHOD fill_list. DATA: flight_tab TYPE TABLE OF demofli, BEGIN OF flight_title, carrname TYPE scarr-carrname, cityfrom TYPE spfli-cityfrom, cityto TYPE spfli-cityto, END OF flight_title, list_layout TYPE lvc_s_layo. SELECT SINGLE c~carrname p~cityfrom p~cityto INTO CORRESPONDING FIELDS OF flight_title FROM ( scarr AS c INNER JOIN spfli AS p ON c~carrid = p~carrid ) WHERE p~carrid = carrid AND p~connid = connid. SELECT fldate seatsmax seatsocc INTO CORRESPONDING FIELDS OF TABLE flight_tab FROM sflight WHERE carrid = carrid AND connid = connid

15

ORDER BY fldate. CONCATENATE flight_title-carrname connid flight_title-cityfrom flight_title-cityto INTO list_layout-grid_title SEPARATED BY space. list_layout-smalltitle = 'X'. list_layout-cwidth_opt = 'X'. list_layout-no_toolbar = 'X'. CALL METHOD list_viewer->set_table_for_first_display EXPORTING i_structure_name = 'DEMOFLI' is_layout = list_layout CHANGING it_outtab = flight_tab. ENDMETHOD.

Listing 13 The instance method FILL_LIST of class SCREEN_HANDLER. This method gives you an impression of how to work with the new ABAP List Viewer that is going to replace the classical ABAP list processing. As with the Tree Control, you have to prepare data in an internal table and pass this table to a method of the List Viewer object. In our case we read detail information from database table SFLIGHT into an internal table FLIGHT_TAB when the user has double-clicked a flight connection in the tree. Besides the actual data, we prepare and pass additional information as the list's title and some of its attributes to the method. Figure 7 shows the screen after selecting a flight connection in the tree.

Figure 7 List display with an ALV control.

Conclusions

16

In this article we showed you the principal concepts of programming screens with the Control Framework using a detailed demonstration program. The principal procedure can be condensed into the following steps: 1. Create container control objects and link them to areas at the screen. 2. Create application control objects and link them to the container controls. 3. Provide data for the controls in data objects, which for the most cases are internal tables of special global types. 4. Send the data to the controls by calling control methods. 5. React on user actions on the controls by defining and registering event handler methods. We did not explain the single control classes, its methods and events in detail, but we emphasized the ABAP Objects programmer's point of view, who uses global classes of the CFW and defines his own local classes to handle the control objects on the screen. In order to learn more about the controls of the control framework you can refer to the documentation of the control classes or to their definition in the class builder of the ABAP Workbench. With that information you can then continue and explore the CFW on your own. As a next step you might react on mouse clicks on the picture and branch for example to a list of airplanes (taken from database table SAPLANE). Then you can introduce context menus for the nodes of the tree, which present the user selected functions after clicking the right mouse button. And last but not least there is much to discover about the ALV, which provides you a complete environment for interactive reporting Horst Keller is senior technical writer in the SAP ABAP & GUI Group. He documents the ABAP language with an emphasis on ABAP Objects. He also develops and teaches classes on ABAP programming. You can reach him at [email protected]. Gisbert Loff is product manager in the SAP ABAP & GUI Group, where he handles all GUI related issues. He has given various lecture presentations and workshops at technical education conferences and SAPPHIREs You can reach him at [email protected].

17