Tutorial for Graphical Framework

Contents

This document consists of the following sections:

• Objectives of this Document

• Getting Started

• Overview: ABAP Objects, Interfaces, Classes, Attributes, Methods, Instances

• Tutorial

  • Step 1: Creating the Report with a Screen

  • Step 2: Creating the Framework for the GFW

  • Step 3: Providing Data

  • Step 4: Creating the Graphics Proxy

  • Solution

  • Step 5: Suggestions for Self-Study

  • Reasons for Errors

Objectives of this Document

This document serves as an introduction ("Getting Started") for developers who want to use the Graphical Framework (GFW) with the ABAP objects interface.

If you only want to display graphics but do not need to use Customizing then the GFW function modules could well fulfill your requirements. In that case you do not need to know about the syntax of the GFW's ABAP objects interface. You should refer to the documentation on the Function Modules Supported.

The aim of this tutorial is to create a simple application (SAPGFW1) with a graphic.

At the end of this document there is a section with possible reasons for errors for situations where the result of programming was not that which was intended.

To achieve a basic understanding of the GFW, in particular of the definition and interaction of the individual components, see the documentation on the Graphical Framework.

Getting Started

The tutorial presupposes the following background knowledge:

• How to create a screen in an SAP system with a very small menu (exit button)

• How the screen can be processed using PBO and PAI.

• ABAP objects syntax

• The following concepts current in object-oriented programming: Interface, Class, Attribute, Method and Instance. These concepts are briefly explained below.

After you have worked through this document you should be able to write your own applications using the GFW.

Overview: ABAP Objects, Interfaces, Classes, Attributes, Methods, Instances

This is a brief summary for those switching over from process-oriented programming to object-oriented programming.

The definitions should help you to understand the tutorial. They are not intended as an introduction to object-oriented programming!

• Interface: Description of which subprograms (methods) can be called.

• Class: Collection of variables (attributes) and subprograms (methods) - if a class (for example, the class CL_CLASSNAME...) provides an interface ("implements the interface"), this means that it has at least those methods defined in the interface (marked as "public").

• Instance: Object belonging to a class. Every instance of a class offers users all the methods of its class. The instance attributes can only be used by this instance; other instances of the same class have their own instance attributes. However, the local attributes in methods are available for every instance. You can only access methods and (public) attributes of a class via instances (for example, DATA C_REF TYPE REF TO CL_CLASSNAME.).

• Attribute: Variable; an attribute is local for all methods in the class for which it is defined; programs/methods belonging to another class can only access attributes marked "public".

• MYVAL = C_REF->PUBLICVAL.

• Method: Subroutines; can be called in all others methods belonging to the class; programs/methods belonging to another class can only call methods marked "public":

• CALL METHOD C_REF->INIT.

• Class Attribute, Class Method: These are exceptions to the rule that every instance has its own attributes: class attributes and class methods are called without an instance and are the same for all instances, that is attributes and static variables have the same contents. => is used to call them, for example:

  CALL METHOD CL_CLASSNAME=>ACTIVATE.

You can find clear examples of the syntax in the mail folder OOROLLOUT in the document "Status information of OO issues ..."

Tutorial

Our objective is to create a report with a window containing a business graphic. There should be text placed around the graphic.

The graphic should be visible in the window directly after the application has been called.

Step 1: Creating the Report with a Screen

Create your example report "My Report" with the screen "100" with a menu and texts as usual.

Place a custom control element (call it GRAPHIC) where you want the graphic to appear.

Tip: It is easy to create a custom control element using the graphical fullscreen editor. Choose the custom control from the toolbox and draw a box on the screen using the mouse. When you release the mouse button you can specify the name of the custom control.

Do not forget to save and activate the screen and menu!

Test your application. Does it correspond to the initial screen in this section except that is does not have a graphic? If necessary, insert the program call ( CALL SCREEN "100").

Step 2: Creating the Framework for the GFW

Now program the framework of the GFW.

To process return values from the GFW the application needs to know the data types used:

TYPE-POOLS gfw.

To use the global classes of the GFW you need to write the following commands:

CLASS cl_gui_cfw DEFINITION LOAD.

CLASS cl_gfw_mux DEFINITION LOAD.

You have to include the required data container as a local class:

* data container

INCLUDE gfw_dc_pres.

All GFW methods send return codes. Therefore you have to define a variable in your program to receive the return codes:

DATA: retval type symsgno.

Insert the multiplexer call in PBO:

**** activate mux (handling of external graphics and synchronizations)

CALL METHOD cl_gfw_mux=>activate IMPORTING retval = retval.

Error analyses for the return codes can consist in simply displaying the corresponding message:

IF retval <> cl_gfw=>ok.

CALL METHOD cl_gfw=>show_msg EXPORTING msgno = retval.

ENDIF.

Insert the call of the dispatcher for events in PAI:

ok_code = sy-ucomm.

* activate event analysis of object-oriented control framework

CALL METHOD cl_gui_cfw=>dispatch.

Step 3: Providing Data

What data should your graphic display?

To supply the data you must create an instance of the data container for business graphics (LCL_DC_PG). The object is accessed using an interface variable. Your application must also recognize an ID which it uses in future to register with the data container.

You must define the following variables:

DATA: dc_inst TYPE REF TO lcl_dc_pres,        "// dc instance
dc_manage TYPE REF TO if_dc_management, "// dc interface handle
my_id_at_dc TYPE i, retval TYPE symsgno."// dc id

            

Create the data container in PBO before the multiplexer is activated:

retval = cl_gfw=>ok.
IF dc_manage IS INITIAL.
*   create and initialize data container
CREATE OBJECT dc_inst
IF sy-subrc <> 0.
CLEAR dc_inst.
ELSE. "//create dc ok
dc_manage = dc_inst.
CALL METHOD dc_manage->init IMPORTING id = my_id_at_dc
retval = retval.
IF retval <> cl_gfw=>ok.
CLEAR dc_inst.
CLEAR dc_manage.
ELSE.
*       PLACEHOLDER: Fill with data
ENDIF.
ENDIF. "// create dc ok
ENDIF. "//dc_manage IS INITIAL.
IF retval <> cl_gfw=>ok.

CALL METHOD cl_gfw=>show_msg EXPORTING msgno = retval.
ENDIF.

            

An empty data container now exists.

You must tell the data container to distribute any existing changes so that your graphic automatically receives data from the data container (especially changes). This is why you should insert an interface method call before the multiplexer is activated:

* **** distribute changes (to all registered graphics proxies)
IF NOT dc_manage IS INITIAL.
CALL METHOD dc_manage->distribute_changes
IMPORTING retval = retval.
IF retval <> cl_gfw=>ok.
CALL METHOD cl_gfw=>show_msg EXPORTING msgno = retval.
ENDIF.
ENDIF.
            

Filling the data container with data can be a very large task so it cannot occur directly in PBO but instead in an application method (for example, FILL_DC for the instance THIS_APPLICATION).

*       fill DC with application data
IF NOT this_application IS INITIAL.
CALL METHOD this_application->fill_dc
EXPORTING dc_manage = dc_manage
IMPORTING retval = retval.
ENDIF.

            

Enter the definition of the application class before PBO:

* application code
CLASS lcl_this_application DEFINITION.
PUBLIC SECTION.
METHODS: fill_dc
IMPORTING dc_manage TYPE REF TO if_dc_management
EXPORTING retval TYPE symsgno.
ENDCLASS.
DATA this_application TYPE REF TO lcl_this_application.
            

The implementation of the application class with the frame for the fill method can be written at the end of the report:

* ---------------------------------------------------------------------- 
* APPLICATION CLASS implementation 
* ----------------------------------------------------------------------
CLASS lcl_this_application IMPLEMENTATION.
METHOD fill_dc.
retval = cl_gfw=>ok.
ENDMETHOD. "//fill_dc
            

Implement the method FILL_DC with the help of the data container method SET_VALUE or SET_OBJ_VALUES.

Hint: The data container attributes 'OBJID', 'X_VAL' and 'Y_VAL' must be filled with data to provide a meaningful display. To provide data for the example GRPID is also filled.

Is your program free of syntax errors?

Step 4: Creating the Graphics Proxy

Once you have programmed the report with the screen and the framework of the GFW and supplied the data the graphic has to be generated.

For this purpose an instance of a business graphics proxy is created. The graphics proxy is accessed (for example, for parametrization) using an interface reference variable.

DATA: gp_inst TYPE REF TO cl_gui_gp_pres. "// gp instance

• Create and initialize the graphics proxy in PBO.

  Note

  Use SAP's BUSG graphic (cl_gui_gp_pres=>co_prod_sapocx) as the graphics product.

  Note

  Create a container object using the name of the subscreen in the dynpro that you defined. Specify this container object as a placeholder (parameter PARENT).

  DATA: CUSTOM_CONTAINER TYPE REF TO CL_GUI_CUSTOM_CONTAINER.
  CREATE OBJECT CUSTOM_CONTAINER
  EXPORTING CONTAINER_NAME = '...'.
                    

• Tell the graphics proxy the names of the attributes in the data container.

  Note: Use GP_INST->SET_DC_NAMES, a method in CL_GUI_GP_PRES.

• If up to this point no error has occurred then the graphics proxy (in PBO as well) can be activated. Otherwise you should clear the proxy and the reference:

  IF retval <> cl_gfw=>ok.
  CALL METHOD gp_inst->if_graphic_proxy~free
  IMPORTING retval = retval2. "//ignore return value(keep 1st)
  CLEAR gp_inst.
  ELSE.
  CALL METHOD gp_inst->if_graphic_proxy~activate
  IMPORTING retval = retval.
  ENDIF.
  
  IF retval <> cl_gfw=>ok.
  CALL METHOD cl_gfw=>show_msg EXPORTING msgno = retval.
  ENDIF. 
                    

Now that you have finished you should test your program. Does it give the right result?

Yes?

Congratulations, now go to step 5.

No?

Have you instantiated your application class (before " THIS_APPLICATION->FILL_DC") ?

* check existence of application instance 
IF this_application IS INITIAL.  
CREATE OBJECT this_application.  
ENDIF.
            

Solution

You can find the solution in the report GFW_PROG_TUTORIAL.

Step 5: Suggestions for Self-Study

You can extend your program yourself. For example, try the following:

• Incorporating a button for activating/deactivating the graphic (graphics proxy methods DEACTIVATE/ACTIVATE)

• Dynamic placing of the graphic (without custom control)

• Using another graphics product (for example, PROD_ID = CL_GUI_GP_PRES=>CO_PROD_CHART)

• Making the graphic interactive

Reasons for Errors