You are on page 1of 35

CL_GUI_ALV_GRID CONSTRUCTOR

Use
This method is called automatically if you use CREATE OBJECT to create an object of class CL_GUI_ALV_GRID . When the control is generated, it is created on the frontend and linked to a container control.

Features
CREATE OBJECT < reference variable to CL_GUI_ALV_GRID> EXPORTING i_shellstyle = < var. of type I > i_lifetime = < var. of type I > i_parent = < ref. var. to CL_GUI_CONTAINER> i_appl_events = < var. of type CHAR01> .

CL_GUI_CUSTOM_CONTAINER CONSTRUCTOR
The constructor method is called automatically when you instantiate the class ( create object statement). You generally pass the parameters of the method in the create object statement. Since the SAP Container is a superclass, its constructor is called indirectly when the constructor method of one of its subclasses is called. create object container exporting clsid = clsid parent = parent style = style dynnr = dynnr repid = repid container_name = container_name lifetime = lifetime autoalign = autoalign no_autodef_progid_dynnr = no_autodef_progid_dynnr exceptions cntl_error = 1 cntl_system_error = 2 create_error = 3 lifetime_error = 4 lifetime_dynpro_dynpro_link = 5 lifetime_dynpro_illegal_parent = 6.

Parameters clsid parent

Description Class ID Parent of the instance, that is, the contain in which the control is to be displayed Controls the appearance and behavior of the control

Possible values

style

Constants from the class CL_GUI_CONTROL that begin with WS_*

dynnr

Number of the screen to which you want to attach the control Report ID: Program to which you want to attach the control Name of the Custom Container defined in the Screen Painter Lifetime management parameter specifying the lifetime of the control cntl_lifetime_imode : The control remains alive for the lifetime of the internal session (that is, until a statement such as leave program or leave to transaction ). cntl_lifetime_dynpro : The control remains alive for the lifetime of the screen (that is, while it remains in the screen stack). It is not destroyed, for example, by a call screen or call transaction statement.

repid

container_name

lifetime

autoalign

Automatic alignment of the container Switches off automatic definition of the program ID and screen number.

Default: None

no_autodef_progid_dynnr

space Program ID and screen number are used automatically (default value) Switches off automatic definition of the program ID and screen number.

RNEK: Data:
cont_ k_code LIKE sy-ucomm, gt_sflight TYPE TABLE OF sflight, gt_sbook TYPE TABLE OF sbook, g_repid LIKE sy-repid, g_max type i value 100, gs_layout TYPE lvc_s_layo, on_main TYPE scrfname VALUE 'BCALVC_TOOLBAR_D100_C 1', cont_on_dialog TYPE scrfname VALUE 'BCALVC_TOOLBAR_D101_C1' , grid1 TYPE REF TO cl_gui_alv_grid, grid2 TYPE REF TO cl_gui_alv_grid, custom_container1 TYPE REF TO cl_gui_custom_container, custom_container2 TYPE REF TO cl_gui_custom_container, event_receiver TYPE REF TO lcl_event_receiver. CREATE OBJECT custom_container1 EXPORTING container_name = cont_on_main EXCEPTIONS cntl_error = 1 cntl_system_error = 2 create_error = 3 lifetime_error = 4 lifetime_dynpro_dynpro_link = 5. CREATE OBJECT grid1 EXPORTING i_parent = custom_container1. gs_layout-grid_title = 'Flights' (100). * allow to select multiple lines gs_layout-sel_mode = 'A'.

Methods of Class CL_GUI_ALV_GRID


CALL METHOD grid1->set_table_for_first_display EXPORTING i_structure_name = 'SFLIGHT' is_layout = gs_layout CHANGING it_outtab = gt_sflight.

Method CONSTRUCTOR set_table_for_first_display refresh_table_display

Application Generate an instance of the ALV Grid Control Display an output table in the control Refresh the data displayed in the control

HTML

  

Elements of the Grid Control Method get_current_cell set_current_cell_via_id get_scroll_info_via_id set_scroll_info_via_id get_selected_cells Application Get indexes and properties of a selected cell Set cursor on a specific cell Get current scroll position Set scroll position Get content and position of selected cells from frontend Select cells in the ALV Grid Control Get indexes of currently selected cells Select cells using index table Get field names of selected columns from frontend Get indexes of selected rows from frontend Select rows HTML

()
X X X

      

set_selected_cells get_selected_cells_id set_selected_cells_id get_selected_columns get_selected_rows set_selected_rows

Layout and Structure Informationen Method get_frontend_fieldcatalog set_frontend_fieldcatalog get_frontend_layout set_frontend_layout set_3d_border Application Get current field catalog from frontend Set field catalog at frontend Get layout structure at frontend Set layout structure at frontend Enable/disable 3D format of ALV Grid Control border HTML

    

Generic Functions

Method get_filtered_entries

Application Get indexes of rows that are not displayed due to a filter set Get filter properties for all columns that have a filter set currently Get values of current subtotals lines Set filter properties for columns Get sort criteria for sorted columns Set sort criteria for columns Get current layout Disallow users to assign their own layout name Use another container control for diagram display Change function code to be executed currently

HTML

         

get_filter_criteria

get_subtotals set_filter_criteria get_sort_criteria set_sort_criteria get_variant save_variant_dark set_graphics_container set_user_command

Event Handling Method register_delayed_event Application Register event DELAYED_CALLBACK or DELAYED_SEL_CHANGED_CALLBACK Trigger event toolbar. HTML

set_toolbar_interactive

This event is triggered by the ALV each time the toolbar of the control needs to be regenerated. To add self-defined functions to the toolbar, you trigger the event using method set_toolbar_interactive and write an event handler method Event parameter E_OBJECT Type Ref To CL_ALV_EVENT_TOOLBAR_SET E_INTERACTIVE Type CHAR01 Meaning The object contains only one attribute with a table for the functions of the toolbar.

If this flag is set, you triggered the event using method set_toolbar_interactive . If this flag is not set, the event was triggered by the ALV Grid Control.

Interfaces Method activate_reprep_interface offline Application Enable report/report interface Check if the ALV Grid Control runs without frontend handling HTML

 

set_table_for_first_display
Use
Display an output table in the ALV Grid Control instance. In the call sequence, you must specify either a reference structure of the Data Dictionary or a suitable field catalog . Before execution, you can use optional parameters to load a layout, sort the table by fields, set a filter for columns and define properties of the grid control. If you want to refresh the data displayed in the output table, use method refresh_table_display . Method set_table_for_first_display must only be called a second time if the structure of the output table changes. Report BCALV_GRID_DEMO of development class SLIS illustrates the simplest way to call this method.

Prerequisites
The output table must either be defined globally or be a public attribute of a class. CALL METHOD < ref. var. to CL_GUI_ALV_GRID> ->set_table_for_first_ display EXPORTING I_BUFFER_ACTIVE I_STRUCTURE_NAME IS_VARIANT I_SAVE I_DEFAULT IS_LAYOUT IS_PRINT IT_SPECIAL_GROUPS IT_TOOLBAR_EXCLUDING IT_HYPERLINK IT_ALV_GRAPHICS CHANGING IT_OUTTAB IT_FIELDCATALOG IT_SORT IT_FILTER

= = = = = = = = = = =

<any type ( ANY )> <string of type DD02L-TABNAME > <structure of type DISVARIANT > <var. of type CHAR01 > <var. of type CHAR01 > <structure of type LVC_S_LAYO > <structure of type LVC_S_PRNT > <internal table of type LVC_T_SGRP > <internal table of type UI_FUNCTIONS > <internal table of type LVC_T_HYPE > <internal table of type DTC_T_TC >

= = = =

<internal table> <internal table of type LVC_T_FCAT > <internal table of type LVC_T_SORT > <internal table of type LVC_T_FILT >

Parameter I_BUFFER_ACTIVE

Meaning Flag to be set by the application if the method call is static. This means the method is always called with the same field catalog. In this case, the field catalog can be held in a special buffer. This accelerates the display of small lists, in particular. Name of the DDIC structure (for example, 'SFLIGHT') for the data in the output table. If you specify this parameter, the field catalog is generated automatically. Determines the layout to be used for displaying the output table. If you use this parameter, you must at least fill field REPORT of the structure of type DISVARIANT . Determines the options available to the user for saving a layout: y y y y 'X': global saving only 'U': user-specific saving only 'A': corresponds to 'X' and 'U' SPACE: no saving

I_STRUCTURE_NAME

IS_VARIANT

I_SAVE

I_DEFAULT

This parameter determines if the user is allowed to define default layouts: y y 'X': Default layouts allowed (default setting) SPACE: Default layouts not allowed

If default layouts are allowed and if such a layout exists and no other layout is specified in IS_VARIANT , the default layout is automatically loaded when this method is called. IS_LAYOUT Determines properties of the grid control. The layout structure has nothing to do with the layout for saving filter, sort, and column properties. Parameter for printing on the backend If in the field catalog the columns were grouped together with field SP_GROUP , you must pass a table with texts for these groups. On the current layout window, it is then possible to use a list box to restrict column selection to one of these groups. This table contains function codes of the toolbar that you want to hide for the lifetime of the ALV Grid Control. The function codes are constant attributes and are prefixed with MC_FC_ . This table assigns a hyperlink address (field HREF of LVC_S_HYPE ) to each handle (field HANDLE of LVC_S_HYPE ). Using this handle, you can then include hyperlinks in the grid. Settings for displaying the ALV list as a diagram (for example, axis labels). The row type of the table has two fields (variables/value pairs):

IS_PRINT IT_SPECIAL_GROUPS

IT_TOOLBAR_EXCLUDING

IT_HYPERLINK

IT_ALV_GRAPHICS

PROP_ID : Assign a constant attribute of the class CL_ALV_GRAPHICS_CU with prefix CO_PROPID_ to this field to determine the changes to be made to the graphic. Use the CL_ALV_GRAPHICS_CU=>CO_PROPID_TITLE attribute, for example, to refer to the title of the diagram. PROP_VAL : The value of the relevant topic, for example, 'My Title'.

IT_OUTTAB IT_FIELDCATALOG

Output table with the data to be displayed Determines the structure of the output table and the format of the data to be displayed Table with sort properties for columns that are to be sorted initially Table with filter properties for columns for which a filter is to be set initially

IT_SORT IT_FILTER

Events of Class CL_GUI_ALV_GRID


The section Working With the ALV Grid Control describes the special points and issues you must consider when you handle events of the ALV Grid Control. User-defined Text Output Event print_end_of_list Application Define output text to be printed at the end of the entire list Define output text to be printed at the beginning of the entire list Define output text to be printed at the end of each page Define output text to be printed at the beginning of each page Define self-defined subtotals texts HTML

    

print_top_of_list

print_end_of_page

print_top_of_page

subtotal_text

Mouse-controlled Actions in the Grid Control Event button_click Application Query a click on a pushbutton in the ALV Grid Control HTML

double_click

Query a double-click on a cell of the ALV Grid control Query a hotspot click on columns defined for this purpose in advance Collect information when elements of the ALV Grid Control are dragged Process information when elements of the ALV Grid Control are dropped Perform final actions after successful Drag&Drop Distinguish between options for Drag&Drop behavior

 
X X X X

hotspot_click

onDrag

onDrop

onDropComplete onDropGetFlavor

Processing of Self-defined and Standard Functions Event before_user_command user_command after_user_command Application Query self-defined and standard function codes Query self-defined function codes Query self-defined and standard function codes HTML

  

Definition of Self -defined Functions Event toolbar menu_button context_menu_request onf1 Application Change, delete or add GUI elements in the toolbar Define menus for menu buttons in the toolbar Change context menu Define self-defined F1 help HTML

 
X

()

rnek: CLASS lcl_event_receiver DEFINITION DEFERRED. event_receiver TYPE REF TO lcl_event_receiver. CLASS lcl_event_receiver DEFINITION . PUBLIC SECTION. METHODS: handle_toolbar FOR EVENT toolbar OF cl_gui_alv_grid IMPORTING e_object e_interactive, handle_user_command FOR EVENT user_command OF cl_gui_alv_grid IMPORTING e_ucomm. PRIVATE SECTION. ENDCLASS. CLASS lcl_event_receiver IMPLEMENTATION . METHOD handle_toolbar. * 2.In event handler method for event TOOLBAR: Append own functions * by using event parameter E_OBJECT. DATA: ls_toolbar TYPE stb_button. stb_button - Structure Ara ubu u d mesi. Yap s FUNCTION ICON UI_FUNC CHAR CHAR 30 CHAR INT4 1 40 1 70 0 30 10 0 0 0 0 Function Code

ICONNAME

Name of an Icon 0 0 Bir kon iin h zl bilgi

QUICKINFO BUTN_TYPE DISABLED TEXT TEXT40

ICONQUICK TB_BTYPE CHAR CHAR CHAR

Ara ubu u d mesi tipi

Etkinle tirilmedi 40 karakter uzunlu undaki metin Yazd r ld

CHECKED

______________________________ ______________________________ _____________________________________________________________________ _______________________________________________________________ ______ ______ ____________________________________________________________ *.................................................................... * E_OBJECT of event TOOLBAR is of type REF TO CL_ALV_EVENT_TOOLBAR_SET. * This class has got one attribute, namly MT_TOOLBAR, which * is a table of type TTB_BUTTON. One line of this table is

* defined by the Structure STB_BUTTON (see data deklaration above). * * A remark to the flag E_INTERACTIVE: * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * 'e_interactive' is set, if this event is raised due to * the call of 'set_toolbar_interactive' by the user. * You can distinguish this way if the event was raised * by yourself or by ALV * (e.g. in method 'refresh_table_display'). * An application of this feature is still unknown... :-) * append a separator to normal toolbar CLEAR ls_toolbar. MOVE 3 TO ls_toolbar -butn_type. APPEND ls_toolbar TO e_object->mt_toolbar. * append an icon to show booking table CLEAR ls_toolbar. MOVE 'BOOKINGS' TO ls_toolbar -function. MOVE icon_employee TO ls_toolbar -icon. MOVE 'Show Bookings' (111) TO ls_toolbar -quickinfo. MOVE 'Detail'(112) TO ls_toolbar -text. MOVE ' ' TO ls_toolbar -disabled. APPEND ls_toolbar TO e_object->mt_toolbar. ENDMETHOD. *------------------------------------------------------------------METHOD handle_user_command. * 3.In event handler method for event USER_COMMAND: Query your * function codes defined in step 2 and react accordingly. DATA: lt_rows TYPE lvc_t_row. CASE e_ucomm. WHEN 'BOOKINGS' . CALL METHOD grid1->get_selected_rows IMPORTING et_index_rows = lt_rows. CALL METHOD cl_gui_cfw=>flush. IF sy-subrc ne 0. * add your handling, for example CALL FUNCTION 'POPUP_TO_INFORM' EXPORTING titel = g_repid txt2 = sy-subrc txt1 = 'Error in Flush'(500). else. perform show_booking_table tables lt_rows. ENDIF. ENDCASE. ENDMETHOD. "handle_user_command *---------------- ------------------------------------------------ENDCLASS.

The fields of the structure we fill are as follows: FUNCTION - The function code for the function BUTN_TYPE - Button type that will be added to the toolbar. ICON - Icon for the button (optional) TEXT - Text for the button (optional) QUICKINFO - Quick info for the button (optional) DISABLED - Adds the button as disabled The Available button types are: 0: Button (normal) 1: Menu and default button 2: Menu 3: Separator 4: Radio button 5: Checkbox 6: Menu entry

CLASS - DEFERRED, LOAD


CLASS class DEFINITION { DEFERRED [PUBLIC]} | LOAD. Effect These two variants of the CLASS statement are used to make the class class known, regardless of the location of the actual definition of the class in the program. These variants do not introduce a declaration part and must not be enclosed using ENDCLASS.

Addition 1
... DEFERRED [PUBLIC]

Effect The variant with the DEFERRED addition makes a class known provisionally in the program. y Without the PUBLIC addition, this variant makes a local class known before its actual definition. The program must contain an actual declaration part for class at a later point in the program. You cannot access individual components of the class before it is actually defined. You need to use this statement if you want to make a reference to a local class before it is defined. With the PUBLIC addition, this variant makes a global class known and defers loading the class until the end of the current program unit. You can only access individual components of the class after it has been loaded. This statement can be used to prevent unwanted recursion when making references to global classes.

Addition 2
... LOAD

Effect

The variant with the LOAD addition loads a global class class from the Class Library. This statement was needed before Release 6.20 if you wanted to access one of the static components of class from within a program, or to declare an event handler for class before class had been loaded automatically. From Release 6.20 onwards, the LOAD addition is only needed if the compilation of an ABAP program fails because it includes recursive accesses of a globa l class. In such cases, you may be able to make the program compilable by explicitly loading the class before recursion. Example In this example, the class c1 uses the class c2 and vice versa. This means that one of the classes must be made known before it is actually defined. The global class cl_gui_cfw is also loaded before one of its static attributes is used. CLASS c1 DEFINITION DEFE RRED. CLASS c2 DEFINITION. PUBLIC SECTION. DATA c1ref TYPE REF TO c1. ENDCLASS. CLASS c1 DEFINITION. PUBLIC SECTION. DATA c2ref TYPE REF TO c2. ENDCLASS. CLASS cl_gui_cfw DEFINITION LOAD. DATA state LIKE cl_gui_cfw=>system_state. An example of using the DEFERRED PUBLIC addition would be a type group in which a reference type is declared with a reference to a global class, which itself contains components with references to this reference type. In this situation, the entire class cannot be loaded before the type group, since the types are not yet known. However, after the CLASS DEFINITION ... DEFERRED PUBLIC statement, the class name can be specified after REF TO without the class having been loaded previously.

Table of contents 1 2 3
3.1 3.2 3.3 3.4 3.5

Introduction Overview of OOPs Concepts Why Object-Oriented ABAP?


ENHANCED LEVEL OF DATA ENCAPSULAT ON MULT PLE INSTANT AT ON CODE REUSE INHER TANCE ADVANCED EVENT HANDL NG CONCEPTS

3.6

SKELETON OF ABAP CLASS

4
4.1 4.2

ABAP Object restrictions


HOW TO USE A GLOBAL CLASS GLOBAL CLASS: CL_GUI_ALV_GRID Commonly used methods set_table_for_first_display Free Get_selected_rows refresh_table_display Commonly Used Events Context_menu_request Data_changed Double_click Toolbar User command Hotspot_click Coloring a row: Coloring a column: Coloring a cell: SAPS CONTAINER CLASS: CL_GUI_SPLITTER_CONTAINER Commonly used methods:

4.2.1 4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.2 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6 4.2.3 4.2.4 4.2.5 4.3 4.3.1 4.3.1.1

get_container set_row_height

Conclusion

6 7

Reference: Appendix

Introduction

The growth of a programmer depends not on following a technology but on moving with the technology and dreaming beyond the technology. This statement fits exactly into the growth profile of an ABAP developer. As a part of Release 4.5, SAP introduced ABAP Objects - the OO extension of ABAP - by extending the ABAP programming language with Classes and Interfaces and the ability to create objects from classes. SAP Basis Release 4.6 delivered the complete version of ABAP Objects by enabling Inheritance - the key feature of OO technology. Then came release 6.1 and 6.2, with highly advanced OO concepts like Friendship between classes and Shared Object concepts. Although SAP has given a clear-cut idea of moving towards a completely Object-Oriented world, how many of us (ABAP developers) are trying to keep aside the conviction that the procedural approach of ABAP development works fine and that there is no need to migrate to a new programming method. The ABAP Objects can considerably improve the productivity by speeding the development time and increasing the application maintainability. This statement might not arouse the interest of most of the programmers (individually) as we have already set a long list of procedures and tools to maintain the programs - Version management tools, Quality assurance systems etc. Regarding the development time, our idea is like this: Programmers are very fast and if they are not, who is in a hurry? Let me take the example of business scenario programmers (especially those in support projects) who get a lot of change requests. These will involve adding a new functionality to the selection screen or removing functionality. What we ABAP developers usually do is, we will go and add /delete the variables and subroutines involved. One fine morning, the customer may ask for some changes or the older version itself. Now we have to remove all the modifications done; search for unused variables, structures and work areas, make a comparison with the older version (if we have not mistakenly done a pretty print)... I hope you can very well get the level of discipline that procedural programming demand. Still we stick on to that merely because that is the way in which we have always done it, and we dont find any reason to change from the conventional method adopted.
ABAP Objects were never intended to completely replace the classical ABAP/4. ABAP Objects is a fully viable object-oriented extension of ABAP, adding full -blown objectoriented features to the latter. This document is just meant to give an overview of ABAP Objects - an attempt to tap some of the myriad merits of the still unexplored OO technology and to give an opportunity for all fellow programmers to move on with the technology.

Why Object-Oriented ABAP?

Since Release 4.6, ABAP has been a hybrid language, with which you can choose whether you want to stay with the procedural programming model - based on function modules,

subroutines, and the handling of events from the runtime environment or, you want to use the object-oriented programming model, which features:
2.1 Enhanced level of Data Encapsulation

The ABAP Objects improve the maintainability and stability of the programs. In procedural programming, all the data objects, the variables and the work areas that we use get populated in a global data area. In a large application, predicting the state of eac object is nearly h impossible. One function might change the application state in such a way that many other functions are affected. Keeping the state stable thus require a lot of discipline. In ObjectOriented programming, the state is kept in objects and the state of an application is defined by its attributes. This maintains the stability of the application. In this case, even if a method fails, the application will continue to run successfully.
2.2 Multiple Instantiation

Multiple instantiation is one among the unique feature of Object-Oriented programming. In procedural programming, you can instantiate a functionality only once, for eg., when we call a function module, it gets loaded into the global memory(instantiated). If the same or another program in the same internal session calls the function again it wont get re-instantiated. Instead, it will work with the global data that is already available in the existing function pool.
2.3 Code Reuse

Modularizations of a program and code reuse are possible in procedural programming by the use of subroutines and function modules. With the procedural method of code reuse, the greatest disadvantage is that it allows the all or none concept. Either you have a piece of code that performs the functionality or else you need to write a new one.
2.4 Inheritance

This feature permits the creation of objects with reference to an existing global class. We can inherit some or all the characteristics of a general (or global) class to specialized classes simply by programming the difference between the two. This is possible through a stable stand-alone interface. In procedural programming, we make use of parameter interface for subroutines and procedural interfaces for the function modules. ABAP Objects enable the programmers to work with an Objects Business Logic through standalone interfaces, rather than working with the objects directly, which relieves the programmer from knowing exactly how the functionality is implemented.
2.5 Advanced Event handling concepts

ABAP Objects make it easy to implement the event-driven programming model. We are wellacquainted with the event concepts in procedural programming like AT-SELECTIONSCREEN, AT-USER COMMAND, AT-LINE SELECTION etc. The main problem with these methods is their implicitness. The programmer has to know the particular program processes (reporting, dialog, selection-screen or list process) in the ABAP runtime environment in order to understand the program flow and handle the events properly. Also, in procedural programming, it is not possible to deactivate an event once it is implemented and we cannot define and trigger our own events. In ABAP Objects, the events are explicitly

declared as components in a class. This gives the freedom to the programmer to explicitly call an event by the command RAISE EVENT. We can also pass some additional parameters that are interested in reacting to the event. We can activate and deactivate the events as required and also can set up multiple handlers for an event. Most of the above-mentioned features are common in all the Object-Oriented programming languages. ABAP Objects is especially a language for business applications. It was designed to be simpler than Java and C++ and it omits complex concepts that lack in benefits (such as multiple inheritance or destructors). On the other hand, for the powerful concept of events and event handling, which are available only via interfaces in other languages, it was a conscious decision to realize them directly as language elements of ABAP Objects. The greatest benefit of ABAP Objects lies in the fact that they are an extension of the former ABAP programming concepts. Procedural/event-based ABAP/4 language runs in the same legacy system and has the following features:
    Runs on the SAP Application Server in the ABAP runtime environment Is downward-compatible with the existing coding Is inter-operable with the procedural coding Embraces the benefits of classical ABAP - for example, Open SQL

These facts offer an evolutionary approach to object-orientation, which leverages SAPs own and its customers investments in existing business processes, functionality, and data. Apart from all these, from the point of view of a developer,
y y

It frees the programmer of the ABAPs runtime implicit control of program flow. ABAP Objects offer better syntax and semantic rules. Most of the error prone concepts (e.g.:- header, for all entries command) are not permitted in the ABAP classes. ABAP Objects is the only platform on which we can use the new SAP technologies like NetWeaver, and all the new advanced GUI concepts like DOI (Desktop Office Integration), BSP (Business Server Pages), CFW (SAP Control Frame Works) etc.

From a business perspective, migration to Object-Oriented ABAP programming will surely impress the clients due to its enhanced processing speed. (A separate kernel has been set up for the ABAP Objects that significantly improves the processing capabilities) Regarding the maintenance, it will reduce the person hours about N times when compared to procedural programming where the factor N depends on the expertise level and how well the object design has been made. As mentioned earlier, it is a scrupulous job for a programmer to make changes on a standard code or a big custom application program. The main reason being, in order to make even a small change, one should know the actual program flow. Analyzing the impact of changes takes a major amount of development time. But while dealing with classes, the developer can activate and deactivate the functionality or create a new functionality simply by commenting

the method calls or implementing a new method inside the class. There is no need to manually delete the variables or structures or work spaces as the automatic garbage collector will clear the entire memory whenever an object is de-referenced.
2.6 Skeleton of abap class

ABAP Object restrictions

Syntax restrictions on ABAP Objects:Declarations Like reference to Data objects only, No implicit lengths or decimal places in Types. No length specifications on data types I,F,D or T;FIELDS,RANGES INFOTYPES, TABLES, NODES, COMMONPARTS, OCCURS, WITH HEADER, NON-LOCAL not permitted TRANSLATE..CODEPAGE and TRANSLATE NUMBER FORMAT not permitted Clearwith NULL,ADD-CORRESPONDING,DIVIDE CORRESPONDING,SUBSTRACT CORRESPONDING,MULTIPLY_CORRESPONDING not allowed. Not permitted on numeric data objects; procedural programming permits this which sometimes shows surprising implicit behaviors. No implicit types in Field symbols: FIELDSYMOLSSTRUCTURE,ASSIGNTYPE,ASSIGN TABLE FIELD not permitted. <> ,=<,=> not allowed . No operational statements between CASE..WHEN.. No header lines; No implicit work areas, no redundant key, compatible work areas, COLLECT, SORTED BY, WRITE TO ITAB not permitted. No implicit type assignment, Compatible initial values only, passing of SY-SUBRC and raising of undefined exceptions not allowed. No joint use of Using and SKIP FIRST SCREEN in calling transactions, Passing formal parameters implicitly in CALL DIALOG not permitted. Database access: NO implicit work areas, READ, LOOP and REFRESH from on Database tables Not permitted.

Conversions Operations:

String processing:

FIELD-SYMBOLS

Logic Expression Control structures Internal tables

Procedures

Program calls:

All these syntax restrictions imposed on the Object-Oriented programming prohibit many obsolete statements and additions, detects and prevents many potentially incorrect data

handling and reduces the implicitness of the coding. For eg., consider the declaration of an internal table. In procedural programming, we make use of tables with header lines. While doing so, in addition to an internal table, a second data object is implicitly created with the same name. This is a significant source of confusion as the developer has to identify whether it refers to a header or a table, which often leads to programming errors. The syntax-enforced Object-Oriented ABAP allows defining a table without the implicit definition of a header-line only.
3.1 How to use a Global Class

Although coding seems to be a bit confusing in the early stage, programming using Objects is much easier than the procedural method. Let us take the case of an ALV grid programming. In procedural concepts, we create an event-driven report and call the function module REUSE_ALV_GRID_DISPLAY with field catalogue, layout and internal tables. Let us see how the same functionality is attained using ABAP Objects. Step by step approach: ALV grid instance needs a container to be linked with the screen. Usually instance of the class CL_GUI_CUSTOM_CONTAINER is used for this purpose. To create a custom container instance, you need to place a custom control area on the screen. 1. Create a screen <100>. 2. Place the custom control on the screen and give the proper name for the control (eg. CONT1).. 3. Declare all the required global fields. Define a variable in the program of type scrfname and value CONT1. 4. DATA: <go_cont1> DATA: <go_grid > TYPE scrfname value CONT1. TYPE REF to cl_gui_alv_grid.

DATA :<go_container> TYPE REF to cl_gui_custom_container. 5. Declare an internal table to hold the output list. (eg.<gt_outtab> ). 6. Call the screen <100> In the PBO of the screen, create an instance for the container (go_container) passing the container name as the scrfnames variable(go_cont1). Create the instance for the alv grid exporting the parent container say go_container. 7. Call screen 100.
a. MODULE status_0100 OUTPUT. b. IF go_container IS INITIAL. 8. Create instance for the container a. CREATE OBJECT <go_container>

i. EXPORTING ii. container_name = '<CONT1>'.

9. Create instance for the grid


i. CREATE OBJECT < go_grid> ii. EXPORTING iii. i_parent = <go_container>.

10. ENDIF. 11. ENDMODULE. 12. Once you have created the instances for the container and grid, you will be able
to view the grid by using the method set_table-for_first_dispaly of the class cl_gui_alv_grid(which is explained in detail later in this bok).

13. In the PAI of the screen, you can handle all the general user commands.
Defining Local Classes Local classes consist of ABAP source code, enclosed in the ABAP statements CLASS ... ENDCLASS. A complete class definition consists of a declaration part and, if required, an implementation part. The declaration part of a class <class> is a statement block: CLASS <class> DEFINITION. ... ENDCLASS. It contains the declaration for all components (attributes, methods, events) of the class. When you define local classes, the declaration part belongs to the global program data. You should therefore place it at the beginning of the program. If you declare methods in the declaration part of a class, you must also write an implementation part for it. This consists of a further statement block: CLASS <class> IMPLEMENTATION. ... ENDCLASS. The implementation part of a class contains the implementation of all methods of the class. The implementation part of a local class is a processing block. Subsequent coding that is not itself part of a processing block is therefore not accessible. 3.2 GLOBAL CLASS: CL_GUI_ALV_GRID

Global class that contains all the methods, attributes and events that are necessary to

display a list in the ALV grid. You can create N number of instances of a class. With the help of the instances, you can call a method with which you can define and change the property of the grid control.
3.2.1 Commonly used methods set_table_for_first_display

3.2.1.1

Its a public method that is used to display an output table in the specified grid control.

Parameters:
Some of the parameters should be passed when u call this method are . Name IS_LAYOUT Type LVC_S_LAYO Function For setting the general graphical layout for the grid. Contains function codes of the toolbar to be excluded from the list (function codes are attributes prefixed with mc_fc_). Internal table of type lvc_s_fcat,Carries the field catalogue informations. Internal table contains the data to be listed in the grid

IT_TOOLBAR_EXCLUDING

UI_FUNCTION

IT_FIELDCATALOG

LVC_S_FCAT

IT_OUTTAB

Sample code:

DATA:go_test DATA:gs_layout DATA:gt_excl DATA:gt_outtab

TYPE REF TO cl_gui_avl_grid. TYPE lvc_s_layo TYPE ui_function WITH HEADER LINE. TYPE STANDARD TABLE OF < t_outtab> WITH HEADER LINE.

DATA:gt_fieldcat

TYPE lvc_s_fcat WITH HEADER LINE.

CALL METHOD go_test->set_table_for_first_display

EXPORTING
Is_layout = gs_layout

It_toolbar_excluding = gt_excl[]

CHANGING
It_outtab It_fieldcatlog = gt_outtab[] = gt_fieldcat[].

3.2.1.2

Free

Public method used to free up the reference variables and along with this method use clear command to clear all the interfaces and attributes of the object.

Sample code: CALL METHOD:


Go_test->free. CLEAR: Go_test.

3.2.1.3

Get_selected_rows

Public method used to get the indexes of the selected row from the grid in case of selecting more than one row from the grid.

Parameters:
Name ET_INDEX_ROWS Type LVC_T_ROW Function Contains the indexes of the selected rows.

Sample code:
Data: lt_rows type lvc_t_row. CALL METHOD: go_test->get_selected_rows IMPORTING et_index_rows = lt_rows.

3.2.1.4

refresh_table_display

Public method used to refresh the output table in the grid control.

Sample code: CALL METHOD:


Go_test->refresh_table_display. 3.2.2 Commonly Used Events Context_menu_request

3.2.2.1

In this event you can add your own defined functions to the existing context menu and you can also hide/disable the existing context menu functions.

Parameters:
Name E_OBJECT (Ref variable) Type CL_CTMENU Function Standard context menu of the ALV grid control.

Sample code:
To add your own options to the existing context menu use the method add function.

CALL METHOD e_object->add_function EXPORTING


fcode = UPDATE text = Update details. After adding the function code you can code for the function code (UPDATE) in the event user command. And if u want to hide/show/disable/enable the existing options u can use these methods i. disable_functions ii. enable_functions

iii. hide_functions. iv. show_functions. for implementing the above functions what you need to do is just pass the constant attributes that precedes with mc_fc_(function codes) of the class cl_gui_alv_grid to a table that is of type ui_functions.

And call the appropriate method and export the function codes to the table. Sample code for hiding the options DATA: lt_fcodes TYPE ui_functions. CLEAR lt_fcodes. APPEND go_test->mc_fc_loc_copy APPEND go_test->mc_fc_col_optimize APPEND go_test->mc_fc_help APPEND go_test->mc_fc_find APPEND go_test->mc_fc_loc_cut APPEND go_test->mc_fc_loc_insert_row APPEND go_test->mc_fc_fix_columns CALL METHOD e_object->hide_functions TO lt_fcode. TO lt_fcode. TO lt_fcode. TO lt_fcode. TO lt_fcode. TO lt_fcode. TO lt_fcode.

EXPORTING
fcodes = lt_fcode.

3.2.2.2

Data_changed

This event gets triggered when the user tries to change any data present in the grid. For controlling the data changes on the grid, ALV uses the instance of the Class CL_ALV_CHANGED_DATA_PROTOCOL and passess it as an attribute to the event Data_Change.By using this method user can get value of the modified cell. List of methods used in the class cl_alv_changed_data_protocol. Method name Get_cell_value Modify_cell Function Used to get the cell value Used to modify the cell content

Values of the changed data are stored in the attributes of this instance.

list of attributes :
Attribute name Mt_mod_cells Function Contains the input value of the modified cell with row-ids and fieldnames( Field validations doesnt happen at this point) Contains proper values of the cell.

Mt_good_cells

Parameters:
Name ER_DATA_CHANGED (reference variable) Type CL_ALV_CHANGED_DATA_PROTOCOL Function Public class that contains the attributes ,methods and events handling the data _change event.

Sample code:

DATA: er_data_changed TYPE REF TO cl_alv_changed_data_protocol. DATA: wa_test DATA : row_index DATA : wa_curr TYPE lvc_s_modi. TYPE lvc-index. TYPE P DECIMALS 2.

LOOP AT er_data_changed->mt_mod_cells INTO wa_test. CASE:<PRICE >. CALL METHOD er_data_changed->get_cell_value. EXPORTING i_row_id i_fieldname IMPORTING e_value = wa_curr. = wa_test-row_id = wa_test-fieldname

CALL METHOD p_er_data_changed->modify_cell EXPORTING i_row_id = wa_test-row_id

i_fieldname = wa_test-fieldname i_value row_index = wa_curr. = wa_test-row_id .

READ TABLE <gt_outtab> INDEX row_index. IF SY-SUBRC = 0. <gt_outtab-price> = wa_curr . ENDIF. <gt_outtab-paymentsum> = <gt_outtab-price> * <gt_outtab-seatsocc>. MODIFY <gt_outtab> INDEX row_index. ENDCASE. ENDLOOP. 3.2.2.3
Double_click

This event gets triggered when the user double clicks on a cell of the control. Parameters:

Name E_ROW E_COLUMN ES_ROW_NO

Type LVC_S_ROW LVC_S_COL LVC_S_ROID

Function Contains the row-id of the clicked cell. Contains the column name of the clicked cell. Contains the numeric row-id of the clicked cell.

Sample code:
DATA: e_row_id e_column_id es_row_id <lt_outtab> TYPE lvc_s_row, TYPE lvc_s_col, TYPE lvc_s_roid, TYPE <gt_outtab>.

READ TABLE <gt_outtab> into <gs_struct> INDEX lvc_s_row-row_id. IF SY-SUBRC = 0


AND e_column_id-fieldname = CARRID.

<lt_outtab> = <gt_outtab>. APPEND lt_outtab.

ENDIF. 3.2.2.4
Toolbar

This event is used to add self defined functions to the existing tool bar. this event gets triggered when each time the toolbar of the control needs to get regenerated . The fields of the structure that normally contains. Field Function Butn_typ Description Function code for the function List of Value 0 1 2 3 4 5 6 Icon Text Quickinfo Disabled. button types Constant cntb_btype_button cntb_btype_dropdown cntb_btype_menu cntb_btype_sep cntb_btype_group cntb_btype_check Meaning Button (normal) Pushbutton with menu Menu Seperator Pushbutton group Checkbox Menu entry

Icon for the button(optional) Text for the button (optional) Tool tip for the button(optional) Adds the button as disabled

Parameters:
Name E_OBJECT Type CL_ALV_EVENT_TOOLBAR_SET Function Contains an attribute(mt_toolbar) with the table for functions of the standard toolbar.

Sample code:
Following step depicts how to add a user defined button on the existing toolbar.

a. b. c.

Define a event handler method for the toolbar event. Declare a structure for adding a toolbar element. Move the relevant values into the structure fields.

d. Use the event parameter e_object to append the attributes for the newly added button in the toolbar. Say, DATA :ls_toolbar TYPE stb_button, ** structure for adding a ** toolbar element. e_object TYPE REF TO CL_ALV_EVENT_TOOLBAR_SET.

CLEAR ls_tolbar. MOVE 0 MOVE DET MOVE DETAILS TO ls_toolbar-butn_type. ****pushbutton. TO ls_toolbar-function. TO ls_toolbar-text.

MOVE Flight details TO ls_toolbar-quickinfo. APPEND ls_toolbar TO e_object->mt_toolbar.

In the event handler method user_command, user can place his own logic into the corresponding function code which is moved into function field of the table.
Note: you can hide the entire tool bar by adding NO_TOOLBAR field to the layout structure.

3.2.2.5

User command

This event gets triggered when the user defines his own function code.you can write your own function under this function code and u can call this function under this event. Parameters:
Name E_UCOMM Type SY_UCOMM Function Function code used for self-defined function

Sample code:
User can query the function codes of the self defined functions under this event. Here is the code that depicts how to query for selecting the details for more than one row from the alv grid.

DATA: e_ucomm DATA:lt_rows DATA:ls_selected_line DATA:ls_row_index DATA:<lt_outtab> CASE: e_ucomm.

TYPE sy-ucomm. TYPE lvc_t_row. TYPE lvc_s_row, TYPE lvc_index. TYPE <gt_outtab>.

WHEN <DET>. CALL METHOD go_test->get_selected_rows


IMPORTING et_index_rows = lt_rows. Clear: lt_outtab. LOOP AT lt_rows INTO ls_selected_line. CLEAR: lt_outtab, gt_outtab. ls_row_index = ls_selected_line-index. READ TABLE gt_outtab into <gt_wa> INDEX ls_row_index.

IF SY-SUBRC = 0.
APPEND lt_outtab. ENDIF. ENDLOOP.

ENDCASE. 3.2.2.6
Hotspot_click

This event is similar to the double click event of the class cl_gui_alv_grid. Its triggered when the user clicks on a column which is designated as a hotspot column which is identified by hand stretch mouse pointer.(you can designate hotspot column when u build the field-catalog by setting the field hotspot to X ) . Parameters:

Name E_ROW_ID E_COLUMN_ID ES_ROW_NO

Type LVC_S_ROW LVC_S_COL LVC_S_ROID

Function Contains the row-id of the clicked cell. Contains the column name of the clicked cell. Contains the numeric rowid of the clicked cell.

Sample code:
DATA: e_row_id TYPE lvc_s_row, e_column_id TYPE lvc_s_col, es_row_id <lt_outtab> TYPE lvc_s_roid, TYPE <gt_outtab>.

READ TABLE <gt_outtab> into <gt_wa> INDEX lvc_s_row-row_id. IF SY-SUBRC = 0


AND e_column_id-fieldname = CARRID. <lt_outtab> = <gt_outtab>. APPEND lt_outtab. ENDIF. 3.2.3 Coloring a row:

For coloring an entire row you need to add one more field in your output list table structure, which is a 4 character field that one is used to fill the color code for the row. Before going further let us discuss how to construct a color code. Color code is a 4 character field that is of the format. Format: Cxyz. Where x-> Color number. y-> 1 0r 0 (1 for inverse ON and 0 for inverse OFF) z->1 or 0 ( 1 for intensified ON and 0 for intensified OFF). Color numbers are listed out in the below table.

x 1 2 3 4 5 6 7

Color gray-blue light gray yellow blue-green green red orange

Intended for headers list bodies totals key columns positive threshold value negative threshold value Control levels

After moving the color code to the field created on the output table structure ,you need to pass this field name to the field INFO_FNAME of the layout structure Sample code:
Add <col_row(4)> type c in the gt_outtab. Move C310 to <gt_outtab>-<col_row>. *col_row is a 4 character field * in the table gt_outtab. Move <COL_ROW> to <gs_layout>-info_fname.

3.2.4

Coloring a column:

Coloring an entire column is very simple .what you need to do is when you build the field catalog make the option EMPHASIZE to X for the column you need make color.
3.2.5 Coloring a cell:

Coloring an cell is similar to coloring a row . you need to add a deep structure field of type LVC_T_SCOL to the output table structure . this deep structure table used to fill the color datas. To color an individual cell , for each cell column append a line to this deep structure table which inturn also contains the column name at field fname and some color values in the col field and 1 or 0 in the field int , inv.

Sample code:
1. Include a field <color_cell> of type lvc_t_scol to the output list table structure. DATA : wa_color DATA : gt_color DATA: row_index TYPE lvc_s_scol. TYPE TABLE of lvc_s_scol. TYPE lvc_index. TO wa_color-fname. TO wa_color-col. TO wa_color-int. TO wa_color-inv.

MOVE SEATSOCC MOVE 6 MOVE 1 MOVE 1

Append wa_color to gt_color. <Gt_outtab>-<color_cell> [] = gt_color[]. Modify gt_outtab index <row_index> 3.3 SAPs CONTAINER

A custom control is an area on a screen. You create them in the Screen Painter, and, like all other screen objects, they have a unique name. You use custom controls to embed controls. A control is a software component on the presentation server, which can be either an ActiveX control or a JavaBean, depending on the SAPgui you are using. They allow you to perform tasks, such as editing texts, locally on the presentation server. The control is driven by the application logic, which still runs on the application server.
3.3.1 CLASS: CL_GUI_SPLITTER_CONTAINER

This class is used to minimize the memory area occupied by the normal container. Here we can create a single custom control area in the screen, and split the container as we require. We can pass these sub-containers to the alv grid.

3.3.1.1

Commonly used methods:

get_container Used to get the sub container that is got spitted from parent container.

Parameters:
Name ROW(exporting) Function Numeric value that is used to represent

the row id of the sub container. Column(exporting) Numeric value that is used to represent the column id of the sub container. Sub container name that is of refernce type cl_gui_container.

Container(receiving)

Sample code:

DATA:<go_cont1> TYPE REF TO cl_gui_container. DATA: go_splitter TYPE REF TO l_gui_splitter_container.

CALL METHOD <go_splitter> ->get_container EXPORTING row =1 column RECEIVING container = <go_cont1>. =1

set_row_height Used to set the height of the sub-container. Parameters:

Name Id Height

Funtion Sub containers id Numerics value that species the height of the sub container.

Sample code:

CALL METHOD <go_splitter>->set_row_height EXPORTING id height =1 = 25.

For those programmers who find it difficult to create the custom containers over the screens, SAP provides a method that does the container-placing for them. What you have to do is to define a class of type cl_gui_alv_grid. While creating the object, pass the attribute cl_gui_container=>screen0 as the parent container. When we use cl_gui_container=>screen0 as parent, the ALVGrid control will automatically use the full screen to display the grid. NO CONTAINER DEFINITION IS REQUIRED.
DATA: cl_alv TYPE REF TO cl_gui_alv_grid

CREATE OBJECT cl_alv EXPORTING i_parent = cl_gui_container=>screen0

You might also like