Article

This article demonstrates how to use controls with ABAP Objects to programsingle­screen user interfaces. It also takes you step­by­step through thedevelopment process and provides sample code that serves as a starting pointfor creating more inviting user interfaces.

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 toclassical training examples, the screen in Figure 1 is much fancier. The upper leftportion shows an airplane graphic that has no functionality ­ it is for visual purposesonly. On the lower left is a tree structure, from which users can select carriers or flightconnections from SAP's flight model. The third pane displays the Web site of theselected carrier or the detail lists for flight connections.

This is just one example of the kinds of easy­to­use, easy­to­navigate interfacesthat you can provide users when you combine the strengths of GUI control technologywith ABAP Objects.

In this article, we show you how to use controls with ABAP Objects to programsingle­screen user interfaces. After providing an overview of the control framework,we will take you step by step through the development process and provide somesample code ­ which will run in R/3 Release 4.6 ­ that you can use as a starting pointfor creating more inviting user interfaces in your own applications.

Figure 1User Interface of the Flight Model ProgramControl Technology OverviewThe R/3 system communicates with the user via screens on the frontend. In classicalABAP programming, screens may contain input/output fields, checkboxes, radiobuttons, and push buttons to interact with the user.

All user actions that raise the runtime event PAI (Process After Input) and therespective processing on the application server are connected to a function code thatis transported to the application server.¹

Controls in GeneralControls 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 orwork alongside classical components ­ both are supported in parallel. SAP currentlysupports ActiveX controls for Microsoft Windows platforms and JavaBeans for the

ABAP Objects in Action: Screen Programming with theControl Frameworkby Horst Keller and Gisbert Loff | SAPinsider

June 1, 2000

by Horst Keller and Gisbert Loff, SAP SAPinsider ­ 2000 (Volume 1), June (Issue 1)

Q&As | Case Studies | Blogs | White Papers | Webinars | Videos | Podcasts | Books | Events | Magazines | Why Subscribe?

Search

FINANCIALS GRC HR SCM CRM BI HANA CLOUD ADMIN/DEV ROADMAP

TRENDING TOPICS

SAP GUI in the Java environment.

Note that controls provide a great deal of functionality and can keep a lot of dataat the presentation server without putting weight on the application server (forexample, during scrolling and editing of texts). On the other hand, frequent dataexchange between the frontend and backend may increase the network load.Therefore, controls are appropriate when most of the work can be done at thefrontend and when exchange with the backend does not occur too often.

Control FrameworkIn order to facilitate programming with controls, starting with Release 4.6, the SAPBasis system provides a control framework (CFW). The CFW encapsulates allavailable controls in global classes of ABAP Objects. To work with controls on yourscreen, simply create objects of these global classes, call their methods, and react ontheir events. Since the CFW classes are part of an inheritance hierarchy, theseclasses provide a standardized interface for most of the common functionality you willfind in the controls.

The CFW distinguishes between container controls and application controls.Application controls are the components you want to use on the screen. Containercontrols provide a software layer that standardizes all layout­related issues and theimplementation of application controls. All application controls must be linked to acontainer control while the container control is linked to an area of the screen (seeFigure 2).

Figure 2Container Controls and Application Controls on ScreensContainer Controls

Container controls provide areas on the screen that can be used for applicationcontrols. The most important container controls are encapsulated in the followingglobal classes²:

CL_GUI_CUSTOM_CONTAINER: When you create an object of thisclass, you must link it to a custom control on a screen via the IMPORTINGparameter container_name of its constructor. You can use the Screen Painter tocreate one or several custom controls within the area of one screen, and you canuse custom controls together with classical screen elements. Any applicationcontrol that you link to a custom container will appear within its screen area.

CL_GUI_DOCKING_CONTAINER: When you create an object of thisclass, you must link it to one of the four edges of a screen. By doing so, youcreate a new area docked to a screen without using the Screen Painter. Anyapplication control that you link to a docking container will appear within thatscreen area.

CL_GUI_SPLITTER_CONTAINER: When you create an object of thisclass, you must link it to an already existing container control. By doing so, yousplit the area of the existing control either vertically or horizontally into two newareas, as was done to create the screen in Figure 1. You can then linkapplication controls to the new areas. You can also nest splitter controls to createmore areas.

Application Controls

After creating objects of container controls, you can create objects of applicationcontrols ­ the components you want to use onscreen. You must link each applicationcontrol to an object of a container control. You can do this by simply passing therespective 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 HTMLdocuments. For example, the new help viewer of the ABAP keyworddocumentation uses an HTML control.

CL_GUI_PICTURE: This control allows you to display any given pictureon an R/3 screen. For example, the airplane in Figure 1 is displayed in a picturecontrol. SAP Easy Access is another example of a picture control as background.

CL_GUI_SIMPLE_TREE: This control allows you to display and workwith a tree structure. In addition to the simple tree, there are also other kinds oftrees available. For example, the Object Navigator of the ABAP Workbench usesa tree control.

CL_GUI_TEXTEDIT: This control implements a full­fledged editor forviewing and maintaining texts. For example, the ABAP Editor uses a texteditcontrol.

Control MethodsYou use the methods defined in the control's classes to work with the controlsdisplayed on the screen. In general, you work with the methods of the applicationcontrols. You would use these, for example, to fill text from an internal table into thetext editor of the textedit control. But sometimes you will also call methods of theCFW. In order to minimize the network load between backend and frontend, methodcalls are buffered in an automation queue before being sent to the frontend atdefined 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 staticmethod cl_gui_cfw=> flush.

Control Events and Event HandlingUser actions on controls can trigger events. However, the events of controls are notclassical screen events, which trigger the PAI processing at the application server andsend a function code. Instead, they are declared as ABAP Objects events in theirglobal wrapper classes. For performance reasons, a user action on controls is notautomatically passed back to the application server. If you want an event to bepassed back to the application server, you must register it in your program using thespecial 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 SETHANDLER statement. This method is then executed on the application server.

Pros and cons: The benefits of using this default technique is that the eventhandler method is executed automatically. There also are no conflicts with theclassical automatic input checks associated with the screen. The disadvantage isthat the contents of the classical screen fields that might exist alongside controlsare 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 functioncode and trigger the PAI event, including a field transport. After PAI has been processed, the PBO eventof the next screen is triggered (see Figure 3).

Figure 3Handling of System Events

Application Events: With this second type of event handling, the event ispassed to the application server and triggers the PAI (see Figure 4). If you wantto handle the event, you must include a method call for cl_gui_cfw=>dispatch inan appropriate PAI dialog module. The dispatch method calls all event handlermethods that are defined and registered with the SET HANDLER statement forthat event. After the event handler has been processed, control returns to the PAImodule and PAI processing continues.

Pros and cons: The advantage of using this method is that you can specify thepoint at which the event is handled. The contents of the screen fields are alsotransported to the application server beforehand. The disadvantage is that thiskind of event handling can lead to conflicts with the automatic input checks onthe screen, which can cause events to be lost.

Why two types of event handling? You have these options because controls maybe displayed on classical ABAP screens, and there may be classical screenelements alongside controls. The flexibility of the two types of event registration

and the methods of the CFW, mentioned above, allow you to steer the sequenceof data transports between frontend and backend. If you do not use any classicalscreen components at all, you can simply work with system events (the defaultmode).

Figure 4Handling of Application Events

Introduction to the Demonstration ProgramOur demonstration program is designed to be as simple as possible. It is meant todemonstrate the basic concepts of programming with GUI controls. Because of this,we omitted all superfluous code, and we did not exploit all the possibilities thatcontrol technology provides. With the information we provide in this article, you cango on to modify the program to learn more. You can find the code in our example atDEMO_ABAP_ OBJECTS_SPLIT_SCREEN in R/3 Release 4.6C or higher.

Program Structure

Figure 5 shows the processing blocks of the demonstration program. The programcontains two local classes, screen_init and screen_handler, which are used to createand fill the controls and to react on the user's input. Since controls are displayed onclassical ABAP screens, we need a small classical framework to call a carrier screenfor our controls. We use the event block LOAD­OF­PROGRAM and two dialogmodules for that purpose.

Listing 1 shows the coding structure of the program. For our demonstrationprogram, we have chosen the program type 1 (executable). Note that we could havetaken one of the other program types that support screens, namely a module pool ora 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 useof the classical reporting events such as START­OF­SELECTION. It is simply acontainer for the three processing blocks of the classical screen framework, shown inFigure 5, and our two local classes.

Figure 5Structure of the Demonstration 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. ... ENDMODULE. Listing 1Layout of the Demonstration Program

The Program at Runtime

Figure 6 shows which objects the program uses to create the screen display ofthe demonstration program, along with the references between these objects.

During screen display, there is no instance of the local class screen_initbecause there is no global reference variable in the program that can point tosuch an instance. An object of screen_init will be created temporarily during eachPBO processing of the screen, where it is used as a factory object to create thecontrol objects from the global classes cl_gui_splitter_container, cl_gui_picture,and cl_gui_ simple_tree. After each PBO processing, the object of screen_initwill be deleted by the garbage collector. The objects of the global classes arekept alive by pointers from the CFW because they are bound to screen areas. Aninstance of screen_handler is registered as an event handler for events of objectcl_gui_simple_tree. This instance itself holds references to objects of the globalclasses cl_gui_ html_viewer and cl_gui_alv_grid. The instances of the globalclasses are linked to controls on the screen via the CFW layer. The two objectsof cl_gui_ splitter_container split the screen in the three areas shown in Figure 1.The objects of the application controls are linked to these areas. The objects ofcl_gui_html_viewer and cl_gui_alv_grid are both linked to the same area.

Figure 6Runtime Objects of the Demonstration ProgramDemonstration Program in DetailThe following sections explain the definitions and the processing blocks of thedemonstration program in detail. (Again, the code shown here is available atDEMO_ABAP_OBJECTS_SPLIT_ SCREEN in Release 4.6C or higher.)

Classical Screen Framework

Listing 2 shows the complete coding of the three classical processing blockslisted in Figure 5. The ABAP runtime environment raises the event LOAD­OF­PROGRAM at the moment when the program is started. The respectiveprocessing block does nothing but call Screen 100. Screen 100 is created withthe Screen Painter. In its screen flow logic, the two dialog modules status_0100and cancel are called during PBO and PAI respectively, the latter with theaddition AT EXIT­COMMAND. We did not use the graphical Screen Painter forour example because we have no classical elements on our screen, and we willuse an implicit method to create a custom control. The PBO module sets a GUIstatus. Within that status, the three function codes BACK, EXIT, and CANCELare defined with function type E (Exit Command) and are activated in the symbolbar. Therefore, the PAI module is called only when the user wants to leave theprogram. The most important action during PBO is calling the static methodinit_screen of class screen_handler. All actual screen handling is encapsulated inthe two local classes.

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 2Classical Processing Blocks of the Demonstration

Program

Local Class Definitions

Listing 3 shows the declaration parts of the two local classes of the program:screen_init and screen_handler. In each of the declaration parts, two visibilitysections are defined by using the statements PUBLIC SECTION and PRIVATESECTION. Only those class components that must be used from the outsideclient are declared in the public sections. All other components are encapsulated

in the private sections. All attributes are reference variables that refer to globalclasses of the CFW. Each local class has an instance constructor and privatemethods that are used to fill the controls with data.

In addition to these general features, our two local classes also have theirown particular features:

Class screen_init has a public static method, init_screen, that can be calledwithout creating an object of that class.

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 inListing 3. Objects of class screen_ init can be created only within classscreen_init itself.

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 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 3Declaration Parts of the Two Local Classes

Static Method init_screen

Listing 4 shows the static method init_screen of class screen_init. The singlepurpose of method init_screen is to create a temporary object of classscreen_init. This is done by using a local reference variable, screen. During theCREATE OBJECT statement, the instance constructor of screen_init isexecuted. Note that after leaving method init_screen, the reference variablescreen is deleted. The object is not referenced anymore and will be deleted bythe next turn of the garbage collector.

METHOD init_screen. DATA screen TYPE REF TO screen_init. CREATE OBJECT screen. ENDMETHOD. Listing 4The Static Method init_screen of Class screen_init

Instance Constructor of screen_init

Listing 5 shows the instance constructor of class screen_init. The instanceconstructor is used to create all the container controls on Screen 100 and two ofthe application controls (picture and tree). Furthermore, it creates an eventhandler for events of the tree control. Most of the data objects that are neededfor this purpose are declared locally within the constructor. The referencevariables of type cl_gui_ container can contain references that point to anycontainer control at the screen.

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 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 5The Instance Constructor of Class screen_init

Creating the Container Controls

The code in Listing 5 demonstrates the process involved in creating the containercontrols in the demonstration program:

1. Create the first splitter container (CREATE OBJECT splitter_h). Theconstructor creates an object of the global class cl_gui_splitter_container using the reference variable splitter_h. In the CREATEstatement, actual parameters are passed to the IMPORTINGparameters of the global class's constructor.

2. Create a Custom Control at Screen 100 (parent = cl_gui_container=>screen0). By passing the static attribute screen0 of class cl_gui_container to the parameter parent, we use the entire area of Screen 100as a custom control implicitly. (This is why we didn't have to use thegraphical Screen Painter for Screen 100 to create a custom control.)

Alternatively, we could create a custom control on Screen 100 with thegraphical Screen Painter and pass its name instead of screen0. Then,only this area would be used for displaying the controls.TIP: When you write more complex programs that work with more than one screen, you

must create custom controls with the graphical Screen Painter in order to distinguishbetween the screens.

3. Split the screen into two columns (columns = 2). We fill theremaining IMPORTING parameters with appropriate values to splitScreen 100 into two columns. For each column, a new container controlis created. References to each new container are stored in a systemtable of the CFW. You cannot access this table from the ABAPprogram. Nevertheless, the table lines point to container control objectsof the program that are currently linked to a screen and prevent theseobjects from being deleted by the garbage collector, even if thecontainer control objects are not referenced in the program itself (seeFigure 6).

TIP: To remove a control object from the program, you must use its method free beforeinitializing all respective reference variables. This method deletes the respective entryfrom the CFW system table.

4. Get references of the two columns into container_left andcontainer_right. After we set some attributes of the columns by callingmethods of splitter_h, we read the references to our containers from theCFW into the local reference variables container_left and container_rightby functional calls of method get_container.

5. Create two rows in the left column (CREATE OBJECT splitter_v). Wefollow the basic principles of steps 1­4 in a similar procedure to split theleft column into two rows. Here, we pass the reference in container_leftto the constructor of cl_gui_splitter_ container and get references of thetwo new container objects into the local reference variables container_top and container_bottom.

Creating the Application Controls By going through the steps listed above, wehave created all the container controls that we need. Now we can go on tocreate our application controls. The process is shown in the code in Listing 5,and involves these steps:

1. Create application controls for the left column (CREATE OBJECTpicture and CREATE OBJECT tree). With the instance constructor ofclass screen_init, we create the two application controls for thecontainers in the left column. In the upper container, we create an objectof cl_gui_picture. In the lower container, we create an object ofcl_gui_simple_tree. We link the objects to the respective containercontrols by passing the references in container_top and container_bottom to their constructor's IMPORTING parameter parent.

2. Create an event handler (CREATE OBJECT event_handler). Since wewant our program to react on user actions in the tree control, we mustprovide and register an event handler:

1. First, we create an object of our local class screen_handler.

2. The constructor of this class demands an IMPORTING parameter oftype cl_gui_container. We pass the reference to the right column'scontainer control.

3. In order to register our object of class screen_handler as an eventhandler for the tree control, we must call the special methodset_registered_events as well as the simple SET HANDLERstatement (see "Control Events and Event Handling" above).

4. The parameters are passed via an internal table of type cntl_simple_events, which is defined in the ABAP Dictionary.

5. By moving a blank character ' ' (default value) and not an 'X' to thecomponent appl_event, we define that the event is handled as asystem event (default) and not as an application event.

3. Send initial data to the application controls (call method: me­>fill picture,me­>fill tree). Finally, the constructor calls the methods fill_picture andfill_tree to initialize the contents of our application controls on thescreen.

Method fill_picture

Listing 6 shows the instance method fill_picture of class screen_init. Themethod fill_picture imports a picture in GIF format from an indx type databasetable abtree into a local internal table pict_tab. The function moduledp_create_url creates a URL for that internal table and passes it to the localvariable url. By passing that URL to method load_picture_from_url of our picturecontrol object, we send the picture to the picture control at the screen. Themethod set_display_mode allows us to set the attributes of the picture displayedin the control.

Instead of working with an internal table, you can also use a local picture filefrom your presentation server and pass its name directly to the parameter url ofmethod load_picture_from_url. Our program has the advantage of working for allusers.

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_tabCHANGING 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 6The Instance Method fill_picture of Class screen_init

TIP:How can you save pictures in an indx type database table? Listing 7shows a little helper routine that fulfills that purpose. Provide your favoritepicture in a folder (for example, C:\TEMP\ of your presentation server) andsimply run this program. The program loads the picture in binary format into aninternal table and exports it to an indx type database table. (We stronglyrecommend that you create your own indx type table instead of using abtree orindx itself!)

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 7Helper Routine to Save GIFs in a Database Table

Method fill_tree

Listing 8 shows the instance method fill_tree of class screen_init. To create atree­like structure within the tree control, you must call method add_nodes andpass an internal table of special structure and contents to that method. Theaddition TYPE TABLE OF in the declaration of node_table in Listing 8 showsthat the line type of that internal table is abdemonode, defined in the ABAPDictionary. You can create such types by copying the global template structuremtreesnode.

The internal table contains one line for each node of the tree. Each node musthave a unique key node_key. The columns relatkey and relatship describe therelations between the nodes. You can also add description texts, change thestandard icons, and so on. In our example, we create a node table from thecontents of database table spfli. The database table spfli is the well­known tableof flight connections from SAP's training and demonstration flight model.

We select all data from spfli into the sorted internal table spfli_tab andprocess this table in a loop. There, we fill the internal table node_table with linesthat represent a tree structure of two hierarchy levels. The attributes of thenodes are set by assigning flags to some columns of node_table. Note that wereplace the standard folder icon with an airplane icon for the subnodes byassigning the internal code "@AV@" to the image columns.

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. Listing 8The Instance Method fill_tree of Class screen_init

TIP: To find the internal codes of all SAP icons, execute the reportSHOWICON.

Instance Constructor of screen_handler

Listing 9 shows the instance constructor of class screen_handler. The instanceconstructor of class screen_init creates an object of class screen_ handler. Thismeans that the execution of the instance constructor of class screen_handler isembedded in the execution of the instance constructor of class screen_init. Itcreates two application control objects, both of which are linked to the right

column of our vertical splitter control. Remember that the instance constructor ofclass screen_init passes the reference to the right column's container control andto the constructor's parameter container in the CREATE OBJECT statement.The application controls can display either HTML pages or lists, but they are notfilled during the constructor's execution yet. Filling these controls depends on theuser's action in the tree control.

METHOD constructor. CREATE OBJECT: html_viewer EXPORTING parent = container, list_viewer EXPORTING i_parent = container.ENDMETHOD. Listing 9The Instance Constructor of Class screen_handler

Method handle_node_double_click

Listing 10 shows the instance method handle_node_double_click of classscreen_handler. This method is declared and registered as an event handler forthe event node_double_click of our tree control object. Therefore, each time auser double­clicks on a node of the tree, it triggers that method. The methodimports the event's EXPORTING parameter node_key, which contains the key ofthe selected node. Depending on the key's contents, the event handler eithercalls method fill_html or fill_list. It also sets the visibility of the two applicationcontrols referenced by html_viewer and list_viewer. Remember that both controlsare linked to the right column of our vertical splitter control. The event handlersteers their alternative display in that container.

As stated above, method calls to the frontend are buffered in an automationqueue. But since there is no automatic synchronization point after handling asystem event on the backend, we must force the system to process thepreceding method calls. To do this, we must call the static methodcl_gui_cfw=>flush. Note that we do not have any regular PAI processing in ourprogram except when the user leaves the screen. The communication betweenfrontend and backend is handled by the CFW. The frontend­to­backendcommunication is triggered by events, and the backend­to­frontendcommunication is triggered by flushes.

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. Listing 10The Instance Method handle_node_double_click of

Class screen_handler

Method fill_html

Listing 11 shows the instance method fill_html of class screen_handler. When auser selects a node, this method reads the value of column URL from thedatabase table SCARR according to the node selected. The selected URL issimply passed to the method show_url of our HTML control, which displays it inits area on the screen.

Beginning with Release 4.6C, the new column URL of the carrier databasetable SCARR will contain the addresses of the carrier's Web sites. To add,change, or update the addresses, you can provide your own data and change theprogram accordingly.

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 11The Instance Method fill_html of Class

screen_handler

Method fill_list

Listing 12 shows the instance method fill_list of class screen_handler. This

method gives you an impression of how to work with the new SAP List Viewer,which will replace classical ABAP list processing. As with the tree control, youhave to prepare data in an internal table and pass this table to a method of theList Viewer object. In our case, we read detail information from database tablesflight into an internal table flight_tab when the user has double­clicked a flightconnection in the tree. In addition to the actual data, we prepare and passadditional information ­ such as the list's title and some of its attributes ­ to themethod. Figure 7 shows the screen after selecting a flight connection in thetree.

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 ORDER BY fldate. CONCATENATE flight_title‐carrnameconnidflight_title‐cityfromflight_title‐citytoINTO 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 12The Instance Method fill_list of Class screen_handler

Figure 7List Display with an ALV ControlConclusionIn this article, we showed you the principal concepts of programming screenswith the control framework using a detailed demonstration program. Thisprocedure 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, in most cases, areinternal 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 eventhandler methods.

In this article, we did not explain the single control classes ­ or their methodsand events ­ in great detail. We simply wanted to provide an overview for theABAP Objects programmer who wants to use global classes of the CFW andwho defines his or her own local classes to handle the control objects on the

Leverage Your Current ITInfrastructure in SAPHANA Deployments

There is more than one way todeploy SAP HANA. As analternative to implementing afully pre­configured SAP HANAappliance, SAP also supports aTailored Datacenter Integration(TDI) model ...

Keys to Success forBarcode Labeling fromSAP

Attend this webinar to find outhow Kerry dramatically reducedlabeling errors, improvedconsistency and cut costs bystandardizing on an EnterpriseLabeling Solution that leveragesSAP. Register today to ...

askSAP Sets Sights onAnalytics, Big Data inLatest Community Call

Details on the Sept. 17#askSAP Analytics InnovationsCommunity Call with SAPMentor Tammy Powlas, SAPexperts Ty Miller and AngelaHarvey, and guest speakerJustin Sears of Hortonworks. ...

screen.

Using this article as a starting point, you can learn more about the features ofthe control framework by referring to the documentation of the control classes orto their definition in the class builder of the ABAP Workbench. With thatinformation, you can then continue to explore the CFW on your own. Forexample, you might create classes that react when a user clicks on a picture. Oryou could look further into tree controls, so that when a user selects a node in atree control, you could introduce context menus for those nodes. Users wouldthen find these when they right­click on a particular node. Finally, there is muchto discover about the ALV, which we covered only briefly. ALV is the best choicefor presenting tabular data on the screen. It replaces classical table controls aswell as classical lists, and it provides a complete environment for interactivereporting.

If you wish to design and improve GUI features that benefit your users, theopportunities are there, and the development process for these interfaces is morestreamlined than ever before. Whichever features you choose to take advantageof, this article can be your springboard to creating an interface that is an effectivetool for your end users.

Horst Keller is information developer in the SAP ABAP & GUI Group. Hedocuments the ABAP language with an emphasis on ABAP Objects. He alsodevelops and teaches classes on ABAP programming and gives workshops attechnical education conferences. You can reach him at horst.keller@sap.com.

Gisbert Loff is product manager in the SAP ABAP & GUI Group, where hehandles all GUI­related issues. He has given various lecture presentations andworkshops at technical education conferences and SAPPHIREs. You can reachhim at gisbert.loff@sap.com.

Did you find this article helpful? Get access to the latestupdates and resources from SAPinsider with a freesubscription.

Get the SAPinsider subscription now »»

COMMENTSPlease log in to post a comment.

No comments have been submitted on this article. Be the first to comment!

More from SAPinsider

SAPinsider is published by WIS Publishing, adivision of Wellesley Information Services.

20 Carematrix Drive, Dedham, MA 02026 USASales and Customer Service: 1(781)751­8799;customer@wispubs.com

© 2015 Wellesley Information Services. All rightsreserved.

Online ISSN #2155­2444, Print ISSN #1537­145X

SAP and the SAP logo are trademarks or registeredtrademarks of SAP SE in Germany and othercountries.

SAPinsiderSAPinsider Conferences & SeminarsSAPinsider Seminars on DemandSAPinsider Store

insiderPROFILESinsiderRESEARCHSAPexperts

ABOUT US CONTACT US PRESS ROOM MEDIA KIT FAQ PRIVACY POLICY SITEMAP