Get table for cl_gui_alv_grid

[Former Member]

Dear all

I have several cl_gui_alv_grid controls and I like to add 1 double-click handler to all those Grids.

Now when doubleclicking, I need to now which table (they have all the same type) is displayed by this grid.

How can I get this information?

thank you

Herbert

[kesavadas_thekkillath]

Hi,

Check this blog by Uwe [Programming of communating ALV|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/21504%3Fpage%3Dlast%26x-order%3Ddate] [original link is broken] [original link is broken] [original link is broken];

[Former Member]

Hi Keshav

I do not know what I should find there... i read the blog but I have no answer on my question.

Herbert

[ravi_lanjewar]

Hi

Try following link

Link:[Ops ALV Programming |http://sap-partner.hu/ABAP_HELP_INFO/An%20Easy%20Reference%20for%20ALV%20Grid%20Control.pdf]

or

Link:[ Ops ALV programming |http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e8a1d690-0201-0010-b7ad-d9719a415907?quicklink=index&overridelayout=true]

[Former Member]

That is all excellent but have no link to my question.

I have 3 ALV Grids (a,b,c).

on the fly I create those grids using different internal tables. Now I need to know, how I can get the internal table of grid b....

Herbert

[ravi_lanjewar]

Hi,

I am assuming you are using 3 custom container and 3 different object of CL_GUI_ALV_GRID.

Define handler 3 different handler class with different name for each object of alv

CLASS lcl_event_receiver DEFINITION.

  PUBLIC SECTION.

    METHODS: handle_double_click
       FOR EVENT double_click OF cl_gui_alv_grid
            IMPORTING e_row e_column es_row_no,

ENDCLASS

CLASS lcl_event_receiver IMPLEMENTATION.

  METHOD handle_double_click.
* Add your source code here
  gv_row_index = es_row_no-row_id.
 
  ENDMETHOD.                           "handle_user_command

ENDCLASS

Register the event handle class 1 to grid_object, evend handler class 2 to grid_object2 and so on....

 SET HANDLER event_receiver->handle_double_click FOR grid_object1.

I think you know which ALV object assign to which internal table for display data better as well as event handler also.

Write you source code for processing in approprite event handler method to process.

[Former Member]

that's exactly what I like to do... now i wanted to get in the event handler the table for the grid where the method was launched. so I don't know if it's possible on a dynamic way.

[MarcinPciak]

that's exactly what I like to do... now i wanted to get in the event handler the table for the grid where the method was launched. so I don't know if it's possible on a dynamic way.

Well I would totally resign from using separate handlers for each grid. Instead use one method. Via optional parameter e_object you will get instance of grid which raised the event. Simply query which of these objects (grids) it is and address respective table

methods handle_dbl_clk for event .... importing e_object.

method handle_dbl_clk.
  field-symbols <tab> type any table.
  data lr_tab type ref to data.

   case e_object.
       when go_grid1.   "check if it is a refernce of your global alv grid1
            get reference of ITAB1 to lr_tab.
       when go_grid2. "check if it is a refernce of your global alv grid2
             get reference of ITAB2 to lr_tab.
       ...
    endcase.

    assign lr_tab->* to <tab>.
     "now you can work with <tab> dynamically
     "it is transparent to you which table you are working with 
endmethod.

Of course this somehow violates good OO design, as you are programming to an instance not an interface, but overally you achieve addressing table dynamically.

Regards

Marcin

[SuhaSaha]

Hey Marcin,

Via optional parameter e_object sender you will get instance of grid which raised the event

Nice learning this, 10 p*ints from me

Of course this somehow violates good OO design, as you are programming to an instance not an interface

Will get back once i finish reading the OO-design principle book you had referred.

Cheers,

Suhas

[Former Member]

Instead if defining 3 handler classes or use a "CASE" in the event handler method ( that is absolutly not dynamic )

You may define one class but create multiple handler INSTANCE

Something like this:

CLASS lcl_event DEFINITION.
  PUBLIC SECTION.
    METHODS:
      constructor
        IMPORTING im_data_table TYPE ANY TABLE.
*       ....
  PRIVATE SECTION.
    DATA:
          table_ref TYPE REF TO data.
ENDCLASS.                    "lcl_event DEFINITION

CLASS lcl_event IMPLEMENTATION.
  METHOD constructor.
    GET REFERENCE OF im_data_table INTO me->table_ref.
  ENDMETHOD.                    "constructor
  METHOD handle_dbl_clk.
    FIELD-SYMBOLS <tab> TYPE ANY TABLE.
    ASSIGN me->table_ref->* TO <tab>.
*    ....

  ENDMETHOD.                    "handle_dbl_clk
ENDCLASS.                    "lcl_event IMPLEMENTATION

* ...
*** First ALV grid creation ***
* ...
* Event registration
CREATE OBJECT event_handler1 " (type ref to lcl_event)
  EXPORTING im_data_table = itab1.
SET HANDLER event_handler1->handle_dbl_clk FOR grid_object1.

*** Next ALV grid creation ***
* ...
* Event registration
CREATE OBJECT event_handler2 
  EXPORTING im_data_table = itab2.
SET HANDLER event_handler2->handle_dbl_clk FOR grid_object2.

Michaël.

[MarcinPciak]

I must say this approach is much better , as the client (handler class) stays unaware which table and object it is really working with. Mine was only covering first one and as I said was not good OO design.

Although you have to host multiple objects (handlers), number of instances should not discourage against flexibility which obviously you achieved here. If developer desired to have another grid he simply registers and creates new handler passing this new table. This could also be improved by appending such new handler to some collection (a table of handlers) in order to avoid multiple object reference definitions.

All in all, good idea and your first post - congrats!

Regards

Marcin

[kurt_slater3]

Hi Herbert

Why not create a 'data managing' class that is responsible for 1) fetching and validating its own data, and 2) displaying this data in an ALV? The internal table and the ALV would be members of this class.

When the event handler fires it knows the instance of the object that triggered the event. If you subclass cl_gui_alv_grid you could create a method to ask its 'data manager' (I can't think of a better name right now) to do whatever it is you want to do with the internal table.

OR

If you find a 'data manager' too cumbersome, then subclass cl_gui_alv_grid so that it is now responsible for fetching and validating its own data. As above, when the event handler fires then the instance can access its own data via the methods you create for it.

In this way, you don't need to know who triggered the event - nor do you care.

[kesavadas_thekkillath]

Hi Herbert,

Are you populating the internal table name while building field catalouge ? There is a method get_frontend_fieldcatalog in class cl_gui_alv_grid which gives the field catalog information. You can check this method by calling it in your hotsot event.

[Former Member]

Hi

You can use get_frontend_fieldcatalog method.

Link: [Fieldcatalogue.|;

Best Regards,

Rodrigo Crespo.

[huseyindereli]

Hi Herbert ,

Have you tried this one ;

* instances
*go_alv01
*go_alv02
*go_alv03

  method handle_double_click .

if go_alv01 = sender.
*triggered from first instance

elseif go_alv02 = sender. 
*triggered from second instance

elseif go_alv03 = sender.
*triggered from third instance

endif.

  endmethod .                   "HANDLE_DOUBLE_CLICK

[MarcinPciak]

Hi Herbert ,
> 
> Have you tried this one ;
> 
> 
* instances
> *go_alv01
> *go_alv02
> *go_alv03
> 
>   method handle_double_click .
> 
> if go_alv01 = sender.
> *triggered from first instance
> 
> elseif go_alv02 = sender. 
> *triggered from second instance
> 
> elseif go_alv03 = sender.
> *triggered from third instance
> 
> endif.
> 
>   endmethod .                   "HANDLE_DOUBLE_CLICK

I knew I mixed parameter name. Of course this should be sender not e_object . Thanks for fulfulling my anwser.

Regards

Marcin

[huseyindereli]

Here , sender parameter stands as the instance of alv grid that event was triggered from.

I forgot writing definition part ;

handle_double_click
     for event double_click of cl_gui_alv_grid
     importing e_row e_column sender,

[ravi_lanjewar]

Hi Herbert Schlup,

I think you get dynamic approch for it as mention by Marcin Pciak.

Kind Rgds

[naimesh_patel]

I guess, everyone has missed the fact that we can get the access of the Event Sender as the parameter SENDER. So, you can achieve it by doing like this:

* definition
    methods: handle_double_click
             for event double_click of cl_gui_alv_grid
             importing e_row
                       e_column
                       es_row_no
                       sender.

Set event handler for all the objects

    SET HANDLER g_event_receiver->handle_double_click
                                  FOR all instances.
   

For the method implementation

method handle_double_click.
   case sender.
      when o_Grid1.
*        grid1 processing
       when o_grid2.       
   endcase.

endmethod.

More information on Sender: [Method - For Event|http://help.sap.com/abapdocu_702/en/abapmethods_event_handler.htm#!ABAP_ADDITION_1@1@]

Regards,

Naimesh Patel

[SuhaSaha]

Hello Naimesh,

I guess, everyone has missed the fact that we can get the access of the Event Sender as the parameter SENDER.

Marcin got 10 p*ints for proposing the same soln

[naimesh_patel]

Suhas - Marcin has mentioned to use E_OBJECT.

Well I would totally resign from using separate handlers for each grid. Instead use one method. Via optional parameter e_object you will get instance of grid which raised the event.

But we can't use the E_OBJECT as it is not defined as the formal parameter in the method signature. Only the SENDER is an implicit parameter in the event.

Regards,

Naimesh Patel

[MarcinPciak]

Naimesh,

Later on I corrected myself

I knew I mixed parameter name. Of course this should be sender not e_object . Thanks for fulfulling my anwser.

Cheers

Marcin