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
Transcript
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.
parent Parent of the instance, that is, the contain in which the control is to be displayed
style Controls the appearance and behavior of the control
Constants from the class CL_GUI_CONTROL that begin with WS_*
dynnr Number of the screen to which you want to attach the control
repid Report ID: Program to which you want to attach the control
container_name Name of the Custom Container defined in the Screen Painter
lifetime 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.
autoalign Automatic alignment of the container
Default: None
no_autodef_progid_dynnr Switches off automatic definition of the program ID and screen number.
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_C1', 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.
CONSTRUCTOR Generate an instance of the ALV Grid Control
set_table_for_first_display Display an output table in the control
refresh_table_display Refresh the data displayed in the control
Elements of the Grid Control
Method Application HTML
get_current_cell Get indexes and properties of a selected cell ()
set_current_cell_via_id Set cursor on a specific cell X
get_scroll_info_via_id Get current scroll position X
set_scroll_info_via_id Set scroll position X
get_selected_cells Get content and position of selected cells from frontend
set_selected_cells Select cells in the ALV Grid Control
get_selected_cells_id Get indexes of currently selected cells
set_selected_cells_id Select cells using index table
get_selected_columns Get field names of selected columns from frontend
get_selected_rows Get indexes of selected rows from frontend
set_selected_rows Select rows
Layout and Structure Informationen
Method Application HTML
get_frontend_fieldcatalog Get current field catalog from frontend
set_frontend_fieldcatalog Set field catalog at frontend
get_frontend_layout Get layout structure at frontend
set_frontend_layout Set layout structure at frontend
set_3d_border Enable/disable 3D format of ALV Grid Control border
Generic Functions
Method Application HTML
get_filtered_entries Get indexes of rows that are not displayed due to a filter set
get_filter_criteria Get filter properties for all columns that have a filter set currently
get_subtotals Get values of current subtotals lines
set_filter_criteria Set filter properties for columns
get_sort_criteria Get sort criteria for sorted columns
set_sort_criteria Set sort criteria for columns
get_variant Get current layout
save_variant_dark Disallow users to assign their own layout name
set_graphics_container Use another container control for diagram display
set_user_command Change function code to be executed currently
Event Handling
Method Application HTML
register_delayed_event Register event DELAYED_CALLBACK or DELAYED_SEL_CHANGED_CALLBACK
X
set_toolbar_interactive Trigger event toolbar.
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 Meaning
E_OBJECTType Ref To CL_ALV_EVENT_TOOLBAR_SET
The object contains only one attribute with a table for the functions of the toolbar.
E_INTERACTIVEType CHAR01
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.
offline Check if the ALV Grid Control runs without frontend handling
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 = <any type ( ANY )> I_STRUCTURE_NAME = <string of type DD02L-TABNAME > IS_VARIANT = <structure of type DISVARIANT > I_SAVE = <var. of type CHAR01 > I_DEFAULT = <var. of type CHAR01 > IS_LAYOUT = <structure of type LVC_S_LAYO > IS_PRINT = <structure of type LVC_S_PRNT > IT_SPECIAL_GROUPS = <internal table of type LVC_T_SGRP > IT_TOOLBAR_EXCLUDING = <internal table of type UI_FUNCTIONS > IT_HYPERLINK = <internal table of type LVC_T_HYPE > IT_ALV_GRAPHICS = <internal table of type DTC_T_TC >
CHANGING
IT_OUTTAB = <internal table> IT_FIELDCATALOG = <internal table of type LVC_T_FCAT >
IT_SORT = <internal table of type LVC_T_SORT > IT_FILTER = <internal table of type LVC_T_FILT >
Parameter Meaning
I_BUFFER_ACTIVE 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.
I_STRUCTURE_NAME 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.
IS_VARIANT 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 .
I_SAVE Determines the options available to the user for saving a layout:
'X': global saving only 'U': user-specific saving only 'A': corresponds to 'X' and 'U' SPACE: no saving
I_DEFAULT This parameter determines if the user is allowed to define default layouts:
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.
IS_PRINT Parameter for printing on the backend
IT_SPECIAL_GROUPS 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.
IT_TOOLBAR_EXCLUDING 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_ .
IT_HYPERLINK 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.
IT_ALV_GRAPHICS 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):
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 Output table with the data to be displayed
IT_FIELDCATALOG Determines the structure of the output table and the format of the data to be displayed
IT_SORT Table with sort properties for columns that are to be sorted initially
IT_FILTER Table with filter properties for columns for which a filter is to be set initially
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 Application HTML
print_end_of_list Define output text to be printed at the end of the entire list
print_top_of_list Define output text to be printed at the beginning of the entire list
print_end_of_page Define output text to be printed at the end of each page
print_top_of_page Define output text to be printed at the beginning of each page
button_click Query a click on a pushbutton in the ALV Grid Control
double_click Query a double-click on a cell of the ALV Grid control
hotspot_click Query a hotspot click on columns defined for this purpose in advance
onDrag Collect information when elements of the ALV Grid Control are dragged
X
onDrop Process information when elements of the ALV Grid Control are dropped
X
onDropComplete Perform final actions after successful Drag&Drop X
onDropGetFlavor Distinguish between options for Drag&Drop behavior
X
Processing of Self-defined and Standard Functions
Event Application HTML
before_user_command Query self-defined and standard function codes
user_command Query self-defined function codes
after_user_command Query self-defined and standard function codes
Definition of Self-defined Functions
Event Application HTML
toolbar Change, delete or add GUI elements in the toolbar
menu_button Define menus for menu buttons in the toolbar
context_menu_request Change context menu X
onf1 Define self-defined F1 help ()
Ö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 UI_FUNC CHAR 70 0 Function Code
ICON ICONNAME CHAR 30 0 Name of an Icon
QUICKINFO ICONQUICK CHAR 30 0 Bir İkon için hızlı bilgi
BUTN_TYPE TB_BTYPE INT4 10 0 Araç çubuğu düğmesi tipi
DISABLED CHAR 1 0 Etkinleştirilmedi
TEXT TEXT40 CHAR 40 0 40 karakter uzunluğundaki metin
*....................................................................* 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
The fields of the structure we fill are as follows:FUNCTION - The function code for the functionBUTN_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 button2: Menu3: Separator4: Radio button5: Checkbox6: 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.
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 DEFERRED.
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.
�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 don�t 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 object-oriented 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�.
2 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 each object is nearly 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 Object-Oriented 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 well-acquainted with the event concepts in procedural programming like AT-SELECTION-SCREEN, 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 SAP�s own and its customers� investments in existing business processes, functionality, and data. Apart from all these, from the point of view of a developer,
It frees the programmer of the ABAP�s 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
3 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
Conversions TRANSLATE..CODEPAGE and TRANSLATE �NUMBER FORMAT not permitted
Operations: Clear�with NULL,ADD-CORRESPONDING,DIVIDE-CORRESPONDING,SUBSTRACT-CORRESPONDING,MULTIPLY_CORRESPONDING not allowed.
String processing: Not permitted on numeric data objects; procedural programming permits this which sometimes shows surprising implicit behaviors.
FIELD-SYMBOLS No implicit types in Field symbols: FIELD-SYMOLS��STRUCTURE,ASSIGN�TYPE,ASSIGN TABLE FIELD not permitted.
Logic Expression <> ,=<,=> not allowed .Control structures No operational statements between CASE..WHEN..Internal tables No header lines; No implicit work areas, no
redundant key, compatible work areas, COLLECT, SORTED BY, WRITE TO ITAB not permitted.
Procedures No implicit type assignment, Compatible initial values only, passing of SY-SUBRC and raising of undefined exceptions not allowed.
Program calls: 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.
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> TYPE scrfname value �CONT1�.
DATA: <go_grid > 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 scrfname�s 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
3.2.1.1 set_table_for_first_display
It�s 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 Type FunctionIS_LAYOUT LVC_S_LAYO For setting the general
graphical layout for the grid.
IT_TOOLBAR_EXCLUDING UI_FUNCTION Contains function codes of the toolbar to be excluded from the list (function codes are attributes prefixed with mc_fc_).
IT_FIELDCATALOG LVC_S_FCAT Internal table of type lvc_s_fcat,Carries the field catalogue informations.
IT_OUTTAB Internal table contains the data to be listed in the grid
Sample code:
DATA:go_test TYPE REF TO cl_gui_avl_grid.
DATA:gs_layout TYPE lvc_s_layo
DATA:gt_excl TYPE ui_function WITH HEADER LINE.
DATA:gt_outtab 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 = gt_outtab[]
It_fieldcatlog = 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 Type FunctionET_INDEX_ROWS LVC_T_ROW 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
3.2.2.1 Context_menu_request
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 Type FunctionE_OBJECT (Ref variable) CL_CTMENU 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 TO lt_fcode.
APPEND go_test->mc_fc_col_optimize TO lt_fcode.
APPEND go_test->mc_fc_help TO lt_fcode.
APPEND go_test->mc_fc_find TO lt_fcode.
APPEND go_test->mc_fc_loc_cut TO lt_fcode.
APPEND go_test->mc_fc_loc_insert_row TO lt_fcode.
APPEND go_test->mc_fc_fix_columns TO lt_fcode.
CALL METHOD e_object->hide_functions
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 FunctionGet_cell_value Used to get the cell valueModify_cell Used to modify the cell content
Values of the changed data are stored in the attributes of this instance.
list of attributes :
Attribute name FunctionMt_mod_cells Contains the input value of the modified
cell with row-ids and fieldnames( Field validations doesn�t happen at this point)
Mt_good_cells Contains proper values of the cell.
Parameters:
Name Type Function
ER_DATA_CHANGED CL_ALV_CHANGED_DATA_PROTOCOL Public class that
(reference variable)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 TYPE lvc_s_modi.
DATA : row_index TYPE lvc-index.
DATA : wa_curr TYPE P DECIMALS 2.
LOOP AT er_data_changed->mt_mod_cells INTO wa_test.
This event gets triggered when the user double clicks on a cell of the control.
Parameters:
Name Type FunctionE_ROW LVC_S_ROW Contains the row-id of the
clicked cell.E_COLUMN LVC_S_COL Contains the column
name of the clicked cell.ES_ROW_NO LVC_S_ROID Contains the numeric
row-id of the clicked cell.
Sample code: DATA: e_row_id TYPE lvc_s_row,
e_column_id TYPE lvc_s_col,
es_row_id TYPE lvc_s_roid,
<lt_outtab> 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 Description
Function Function code for the function
Butn_typ List of button types
Value Constant Meaning
0 cntb_btype_buttonButton (normal)
1 cntb_btype_dropdownPushbutton with menu
2 cntb_btype_menu Menu3 cntb_btype_sep Seperator
4 cntb_btype_group Pushbutton group
5 cntb_btype_check Checkbox
6 Menu entry
Icon Icon for the button(optional)
Text Text for the button (optional)
Quickinfo Tool tip for the button(optional)
Disabled. Adds the button as disabled
Parameters:
Name Type Function
E_OBJECT CL_ALV_EVENT_TOOLBAR_SET 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. Define a event handler method for the toolbar event.
b. Declare a structure for adding a toolbar element.
c. 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� TO ls_toolbar-butn_type. ****pushbutton.
MOVE �DET� TO ls_toolbar-function.
MOVE �DETAILS� 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 Type Function
E_UCOMM SY_UCOMM 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 TYPE sy-ucomm.
DATA:lt_rows TYPE lvc_t_row.
DATA:ls_selected_line TYPE lvc_s_row,
DATA:ls_row_index TYPE lvc_index.
DATA:<lt_outtab> TYPE <gt_outtab>.
CASE: e_ucomm.
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 Type FunctionE_ROW_ID LVC_S_ROW Contains the row-id of the
clicked cell.E_COLUMN_ID LVC_S_COL Contains the column name
of the clicked cell.ES_ROW_NO LVC_S_ROID Contains the numeric row-
id of the clicked cell.
Sample code:
DATA: e_row_id TYPE lvc_s_row,
e_column_id TYPE lvc_s_col,
es_row_id TYPE lvc_s_roid,
<lt_outtab> 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 Color Intended for
1 gray-blue headers
2 light gray list bodies
3 yellow totals
4 blue-green key columns
5 green positive threshold value
6 red negative threshold value
7 orange 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 TYPE lvc_s_scol.
DATA : gt_color TYPE TABLE of lvc_s_scol.
DATA: row_index TYPE lvc_index.
MOVE �SEATSOCC� TO wa_color-fname.
MOVE �6� TO wa_color-col.
MOVE �1� TO wa_color-int.
MOVE �1� TO wa_color-inv.
Append wa_color to gt_color.
<Gt_outtab>-<color_cell> [] = gt_color[].
Modify gt_outtab index <row_index>
3.3 SAP�s 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 Function
ROW(exporting) 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.
Container(receiving) Sub container name that is of refernce type cl_gui_container.
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 = 1
RECEIVING
container = <go_cont1>.
set_row_height
Used to set the height of the sub-container.
Parameters:
Name Funtion
Id Sub container�s id
Height Numerics value that species the height of the sub container.
Sample code:
CALL METHOD <go_splitter>->set_row_height
EXPORTING
id = 1
height = 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.
