Power of ABAP Objects: Overcome the Restrictions of SALV Model

[naimesh_patel]

Update (05-Mar-2014) - Since after SCN migration to the new platform, the code formatting is gone. Please visit - SALV Table 10 – Editable SALV Model (Overcome the restriction of SALV Model) (outside SCN) for a formatted version.

 

We all know that ABAP Object is very powerful over the classical ABAP. Here I want to share one of my best experiments with the ABAP objects to overcome the restrictions of SALV mdoel.

 

Background
I was reading the help on the CL_SALV_TABLE to get more insight of how to use this new SALV model effectively. When I came across the section Recommendation and Restriction, I was amazed by reading "Tables displayed with ALV are not ready for input".



It was very hard for me to understand this restriction because: The new SALV model is unified object oriented model which has kind of wrapper classes which are ultimately calling the FM REUSE_ALV_GRID_DISPLAY or REUSE_ALV_LIST_DISPLAY; class GL_GUI_ALV_GRID and so on. So, if the ALV created with the CL_GUI_ALV_GRID can be ready for input, why can’t the ALV created with the SALV model be the "Ready for input"? This propelled me to analyze how we can make the ALV Full-screen as "Set ready for Input".

 

Journey to find the solution
By putting breakpoints and debugging, I came to know that when I tried to generate the fullscreen ALV, it calls the FM REUSE_ALV_GRID_DISPLAY and this FM in turn uses the class CL_GUI_ALV_GRID to generate the ALV.

Before couple of months, I came across a very powerful function module GET_GLOBALS_FROM_SLVC_FULLSCR which gives us the object of type GL_GUI_ALV_GRID which was created to generate the fullscreen ALV. I have used this FM in couple of programs to achieve some functionality which is not possible using the FM REUSE_ALV_GRID_DISPLAY. Some of them:

• Move Cursor to next row by pressing enter in Full-screen ALV


• Full-screen ALV: Disable DELTE key of Keyboard


• Full-screen ALV: Change Subtotal


• Re: Can we scroll to the last page of an alv grid?

Basically, to achieve this type of not achievable functionality of the Fullscreen ALV, I get the object using the FM GET_GLOBALS_FROM_SLVC_FULLSCR and use the methods available in the CL_GUI_GRID_DISPLAY followed by the refresh method to refresh the ALV.

 

Based on the assumption - if I get the ALV object from the SALV model than I can make the SALV model ALV to "Set Ready for input" -  I have started searching the ALV object in the SALV model. At the very top node of the SALV model CL_SALV_MODEL, I got the methods (GET_GRID) which can provide me the ALV grid object.

UML diagram contains the SALV hierarchy and visibility of the R_CONTROLLER:



Class CL_SALV_MODEL has a protected attribute R_CONTROLLER which has everything I need to get to GRID object. So, I tried to access that attribute directly, but obviously I didn’t work as I didn’t have the object reference for the CL_SALV_MODEL. By this point of time, I have tried all the normal ways to get the access the R_CONTROLLER - like Feild-symbol to access the object from memory but that didn't work either.

 

Solution
I knew that I have to think in a different way, and I tried to inherite the class from the class CL_SALV_MODEL_LIST, passed the ALV model to the class and tried to access the R_CONTROLLER and BINGO - I am able to access the R_CONTROLLER in my inherited class.

UML Diagram shows the iherited class along with the existing SALV model:



 

Steps to follow:
1. Inherited a local class LCL_SALV_MODEL from the CL_SALV_MODEL_LIST
2. Generate SALV model to generate the ALV object
3. Used narrow casting to get the CL_SALV_MODEL object from the ALV object
4. Passed this CL_SALV_MODEL object to the inherited class LCL_SALV_MODEL. Since LCL_SALV_MODEL is inherited from the CL_SALV_MODEL_LIST, it allows me to access the R_CONTROLLER of the CL_SALV_MODEL.
5. Get the GRID object from the object MODEL -> Controller -> Adapter -> Grid.
6. Set the Layout for EDIT and Refresh the ALV.

 

When we run the report, ALV will not come directly in the input mode:


As soon as we press the "My Function" button, ALV will change into editable ALV. This ALV will have its separate GUI Status which contains all the required buttons for the Editable ALV.


 

Code Snippet
UML diagram for code snippet:



 

Here is the code, which I used to get the access of the GRID object from the SALV model and to make ALV editable. Here I have used the PF-STATUS avaliable in the report program SALV_DEMO_TABLE_EVENTS for easy installation of this demo report.

*&---------------------------------------------------------------------* *& Report  ZTEST_NP_EDIT_SALV *& Overcome the restriction of the SALV model using the power of the *&   Object Oriented ABAP *&---------------------------------------------------------------------*  REPORT  ztest_np_edit_salv.  *----------------------------------------------------------------------* *  Define the Local class inheriting from the CL_SALV_MODEL_LIST *  to get an access of the model, controller and adapter which inturn *  provides the Grid Object *----------------------------------------------------------------------* CLASS lcl_salv_model DEFINITION INHERITING FROM cl_salv_model_list.    PUBLIC SECTION.     DATA: o_control TYPE REF TO cl_salv_controller_model,           o_adapter TYPE REF TO cl_salv_adapter.      METHODS:       grabe_model         IMPORTING           io_model TYPE REF TO cl_salv_model,        grabe_controller,        grabe_adapter.     PRIVATE SECTION.     DATA: lo_model TYPE REF TO cl_salv_model.  ENDCLASS.                    "LCL_SALV_MODEL DEFINITION  *----------------------------------------------------------------------* * Event handler for the added buttons *----------------------------------------------------------------------* CLASS lcl_event_handler DEFINITION.    PUBLIC SECTION.     METHODS:       on_user_command FOR EVENT added_function OF cl_salv_events         IMPORTING e_salv_function.  ENDCLASS.                    "lcl_event_handler DEFINITION   *----------------------------------------------------------------------* * Local Report class - Definition *----------------------------------------------------------------------* CLASS lcl_report DEFINITION.    PUBLIC SECTION.      TYPES: ty_t_sflights TYPE STANDARD TABLE OF sflights.      DATA: t_data TYPE ty_t_sflights.      DATA: o_salv       TYPE REF TO cl_salv_table.     DATA: o_salv_model TYPE REF TO lcl_salv_model.       METHODS:       get_data,        generate_output.  ENDCLASS.                    "lcl_report DEFINITION  *----------------------------------------------------------------------* * Global data *----------------------------------------------------------------------* DATA: lo_report TYPE REF TO lcl_report.  *----------------------------------------------------------------------* * Start of selection *----------------------------------------------------------------------* START-OF-SELECTION.    CREATE OBJECT lo_report.    lo_report->get_data( ).    lo_report->generate_output( ).   *----------------------------------------------------------------------* * Local Report class - Implementation *----------------------------------------------------------------------* CLASS lcl_report IMPLEMENTATION.    METHOD get_data.  *   test data     SELECT * FROM sflights            INTO TABLE me->t_data            UP TO 30 ROWS.    ENDMETHOD.                    "get_data    METHOD generate_output.  *...New ALV Instance ...............................................     TRY.         cl_salv_table=>factory(           EXPORTING *          r_container    = w_alv1             list_display = abap_false           IMPORTING             r_salv_table = o_salv           CHANGING             t_table      = t_data ).       CATCH cx_salv_msg.                                "#EC NO_HANDLER     ENDTRY.  *...PF Status....................................................... *   Add MYFUNCTION from the report SALV_DEMO_TABLE_EVENTS     o_salv->set_screen_status(       pfstatus      =  'SALV_STANDARD'       report        =  'SALV_DEMO_TABLE_EVENTS'       set_functions = o_salv->c_functions_all ).  *...Event handler for the button.....................................     DATA: lo_events TYPE REF TO cl_salv_events_table,           lo_event_h TYPE REF TO lcl_event_handler.  * event object     lo_events = o_salv->get_event( ).  * event handler     CREATE OBJECT lo_event_h.  * setting up the event handler     SET HANDLER lo_event_h->on_user_command FOR lo_events.   *...Get Model Object ...............................................     DATA: lo_alv_mod TYPE REF TO cl_salv_model.  *   Narrow casting     lo_alv_mod ?= o_salv.  *   object for the local inherited class from the CL_SALV_MODEL_LIST     CREATE OBJECT o_salv_model.  *   grabe model to use it later     CALL METHOD o_salv_model->grabe_model       EXPORTING         io_model = lo_alv_mod.  *...Generate ALV output ...............................................     o_salv->display( ).     ENDMETHOD.                    "generate_output  ENDCLASS.                    "lcl_report IMPLEMENTATION  *----------------------------------------------------------------------* * LCL_SALV_MODEL implementation *----------------------------------------------------------------------* CLASS lcl_salv_model IMPLEMENTATION.    METHOD grabe_model.  *   save the model     lo_model = io_model.    ENDMETHOD.                    "grabe_model    METHOD grabe_controller.  *   save the controller     o_control = lo_model->r_controller.    ENDMETHOD.                    "grabe_controller    METHOD grabe_adapter.  *   save the adapter from controller     o_adapter ?= lo_model->r_controller->r_adapter.    ENDMETHOD.                    "grabe_adapter  ENDCLASS.                    "LCL_SALV_MODEL IMPLEMENTATION  *----------------------------------------------------------------------* * Event Handler for the SALV *----------------------------------------------------------------------* CLASS lcl_event_handler IMPLEMENTATION.    METHOD on_user_command.      DATA: lo_grid TYPE REF TO cl_gui_alv_grid,           lo_full_adap TYPE REF TO cl_salv_fullscreen_adapter.      DATA: ls_layout TYPE lvc_s_layo.      CASE e_salv_function.  *     Make ALV as Editable ALV       WHEN 'MYFUNCTION'.  *       Contorller         CALL METHOD lo_report->o_salv_model->grabe_controller.  *       Adapter         CALL METHOD lo_report->o_salv_model->grabe_adapter.  *       Fullscreen Adapter (Down Casting)         lo_full_adap ?= lo_report->o_salv_model->o_adapter.  *       Get the Grid         lo_grid = lo_full_adap->get_grid( ).  *       Got the Grid .. ?         IF lo_grid IS BOUND.  *         Editable ALV           ls_layout-edit = 'X'.  *         Set the front layout of ALV           CALL METHOD lo_grid->set_frontend_layout             EXPORTING               is_layout = ls_layout.  *         refresh the table           CALL METHOD lo_grid->refresh_table_display.          ENDIF.      ENDCASE.    ENDMETHOD.                    "on_user_command  ENDCLASS.                    "lcl_event_handler IMPLEMENTATION

 

Example 2: Background Wallpaper in ALV created using SALV model
When we pass the parameter I_BACKGROUND_ID in the function module REUSE_ALV_GRID_DISPLAY, we will get the background wallpaper in the top of page section of the ALV.

SALV model uses the class CL_SALV_FORM_DYDOS to generate the TOP-OF-PAGE header from the SALV Form object (CL_SALV_FORM). CL_SALV_FORM is used to generate the Header in the SALV model.

When SALV model creates an object for the CL_SALV_FORM_DYDOS, it doesn’t pass the Wallpaper picture. Thus, we are not able to get the header background wallpaper in the SALV model.

To get the wallpaper in the header, we can use the same solution which we have used to make Editable ALV.

ALV header without wallpaper using the SALV model:



ALV header with the wallpaper using the SALV model:



 

Code snippet to get the header with the wallpaper:

Get the Header in the SALV:

* Code comes before the calling the Display method of SALV * O_SALV->DISPLAY( ) *...Header.......... ...............................................     DATA: lo_header  TYPE REF TO cl_salv_form_layout_grid,           lo_h_label TYPE REF TO cl_salv_form_label,           lo_h_flow  TYPE REF TO cl_salv_form_layout_flow.  *   header object     CREATE OBJECT lo_header.  *   information in Bold     lo_h_label = lo_header->create_label( row = 1 column = 1 ).     lo_h_label->set_text( 'Header in Bold' ).  *   information in tabular format     lo_h_flow = lo_header->create_flow( row = 2  column = 1 ).     lo_h_flow->create_text( text = 'This is text of flow' ).  *   set the top of list using the header for Online.     o_salv->set_top_of_list( lo_header ).

Set the background wallpaper by accessing the GRID and TOP-of-LIST object

* Code comes in the event handler of the added button.  *       Get the Grid         lo_grid = lo_full_adap->get_grid( ).  *       Got the Grid.. ?         IF lo_grid IS BOUND.            DATA: lo_form_tol TYPE REF TO cl_salv_form,                 lo_dydos    TYPE REF TO cl_salv_form_dydos.  *         Get the Top of list object using the adapter           CALL FUNCTION 'GET_GLOBALS_FROM_SLVC_FULLSCR'             EXPORTING               ir_salv_fullscreen_adapter = lo_full_adap             IMPORTING               er_form_tol                = lo_form_tol.  *         Got the Top Of List object.. ?           IF lo_form_tol IS BOUND.  *           get the object using the Wide Casting             lo_dydos ?= lo_form_tol.  *           set the wallpaper             lo_dydos->set_wallpaper( 'ALV_BACKGROUND' ).  *           refresh the table             CALL METHOD lo_grid->refresh_table_display.            ENDIF.          ENDIF.

[thomas_jung]

Just a word of warning.  You are obviously doing things that SAP never intended when they designed the ALV Object Model. Limitations and protected or private attributes are used for a reason and circumventing them can lead to inconsistencies and/or lack of support by SAP down the road.

[naimesh_patel]

Hello Thomas,

Thanks for the important point, I forgot to mention in the blog.

I understand that SAP has not designed the way, I have tried to use it. Can you please help me to understand why I should not inherite the a class from the class CL_SALV_MODEL_LIST and use the protected attribute R_CONTROLLER? If access to protected attribute R_CONTROLLER leads to inconsistency, the attribute must be private and there may be some SET/GET methods to access the attribute within the SALV model but not outside of SALV.

Regards,
Naimesh Patel

[alejandro_bindi]

Actually I think the hint you have that you shouldn't be doing what you've done here, is that the CL_SALV_TABLE class, which is the one you should really be inheriting, is marked as Final (not inheritable).

By extending CL_SALV_MODEL_LIST instead, you're certainly loosing some functionality, furthermore it is an Abstract class.
It may still work for now, but you're headed for trouble.

[alejandro_bindi]

I may add, the question should really be: "How to know if a standard class is supposed / can be inherited by a customer or not?" (aside of "hints").
In this particular case, although technically possible, it's not supposed to.

We know when we run a risk by reusing a function module, when it's not released. How to know this for classes? (I know there is an "Internally released" flag which is relevant for SAP developments only)
Maybe this topic deserves a forum thread on its own.

[Former Member]

Naimesh,
Congrats first for coming out with a solution
I just had a quick look  at the code My doubt is
why do you need a casting operator here
*   Narrow casting
    lo_alv_mod ?= o_salv.
lo_alv_mod is of superclass type reference and o_salv is a subclass type of cl_salv_table . Normally we do not require this operator
You can just assign like below
lo_alv_mod  = o_salv.

[naimesh_patel]

Hello Arshad,

Yes, we don't need the casting operator. Thanks for pointing that out. I was trying different ways to achieve this functionality and I forgot to remove the casting operator from the final program.

Regards,
Naimesh Patel

[Former Member]

Hey,

I haven't tried at all on this Class, but what about Enhancing the CL_SALV_TABLE class, and add some method to change restricted attributes, or redefine existing methods ?

This could do the job, and be compliant?

[Former Member]

The object model is not!!!!  designed für input.
In the editable grid special attributes are set, special events are raised (see note 695910) and there are methods which are not passed or implemented by the object model.
If you are making the grid ready for input as described above, you will miss a lot of needed influences in the object model like the event  CHECK_CHANGED_DATA .
So, the classes of the object model like CL_SALV_TABLE and CL_SALV_MODEL_LIST are set final or privat on purpose !
Because people are starting to do what you are proposing and are running into trouble and then asking us for help, I would recomment to close this blog.

Regards Rudi Niessen
Development Manager ALV

[Former Member]

Hello I guess you have been using the class CL_SALV_TABLE for the ALV.
My question is that how can we add the Boxes found on the left of the rows so that when we click on the box, the whole row is selected. I have been trying to look for the solution but in vain...
Can you please help me out?

Thanks and Regards,

Pramod.

[lorenzo_nicora2]

Dear Rudi,
can you tell us more about using directly CL_GUI_ALV_GRID instead?
I'm using it now in several reports (with and without editable fields) and it works fine (up to now).... BUT the class is marked for internal release (i'm on 640) and note 695910 is quite explicit about editable options.

So my question is: should I change strategy about editable grids and switch back to table controls for custom developments?

Thanks,
Lorenzo Nicora

[Former Member]

hi. I am trying to understand why we shouldn't do this. can someone explain to me ? what part of the implementation lets us know that this shoudn't be done?
thanks for you replies

"Actually I think the hint you have that you shouldn't be doing what you've done here, is that the CL_SALV_TABLE class, which is the one you should really be inheriting, is marked as Final (not inheritable)."
-->yes, CL_SALV_TABLE is final but he is not extending this class. he can't extend CL_SALV_TABLE. he is extending an abstract class. I think you made a typo?



"By extending CL_SALV_MODEL_LIST instead, you're certainly loosing some functionality, furthermore it is an Abstract class.
It may still work for now, but you're headed for trouble. "
--> I am not sure why he is losing functionality here. he is INHERITING FROM cl_salv_model_list and using REF TO cl_salv_table. shouldn't this add more functionality ? ( he has access to more methods?)

thanks

[Former Member]

"Just a word of warning. You are obviously doing things that SAP never intended when they designed the ALV Object Model. Limitations and protected or private attributes are used for a reason and circumventing them can lead to inconsistencies and/or lack of support by SAP down the road."
--> can you explain to me what he did wrong?
he NHERITING FROM cl_salv_model_list. so why can't he not use this protected attributes?

[Former Member]

"I understand that SAP has not designed the way, I have tried to use it. Can you please help me to understand why I should not inherite the a class from the class CL_SALV_MODEL_LIST and use the protected attribute R_CONTROLLER? If access to protected attribute R_CONTROLLER leads to inconsistency, the attribute must be private and there may be some SET/GET methods to access the attribute within the SALV model but not outside of SALV."
-->what makes you say that SAP was not designed this way? I don't get it. You are inheriting a abstract class and to get to controller and adapter from it.. why is this so problematic?
can you explain?
thanks

[RobinV]

Hi Naimesh,

I like your blog. Although it is not supported by SAP, sometimes it is just fun to try something new.

There is also another solution to get the r_controller. You can inherit a friend class from the ALV for example the class CL_SALV_CONTROLLER.
The you can access all the variables.

Below an example of how an class-method could help.

Regards, Robin


*----------------------------------------------------------------------*
* CLASS lcl_alv_om_tool DEFINITION
*----------------------------------------------------------------------*
* Simple way to make an ALV OM editable
*----------------------------------------------------------------------*
CLASS lcl_alv_om_tool DEFINITION INHERITING FROM cl_salv_controller.
  PUBLIC SECTION.
    CLASS-METHODS set_editable IMPORTING  io_alv       TYPE REF TO cl_salv_table
                                          iv_editable  TYPE sap_bool.
ENDCLASS.                    "lcl_alv_om_tool DEFINITION



*----------------------------------------------------------------------*
* CLASS lcl_alv_om_tool IMPLEMENTATION
*----------------------------------------------------------------------*
* Simple way to make an ALV OM editable
*----------------------------------------------------------------------*
CLASS lcl_alv_om_tool IMPLEMENTATION.
  METHOD set_editable.
    DATA ls_layout      TYPE lvc_s_layo.
    DATA lo_full_adap   TYPE REF TO cl_salv_fullscreen_adapter.
    DATA lo_grid        TYPE REF TO cl_gui_alv_grid.

*   Fullscreen Adapter (Down Casting)
    lo_full_adap ?= io_alv->r_controller->r_adapter.

*   Get the Grid
    lo_grid = lo_full_adap->get_grid( ).

    IF lo_grid IS NOT BOUND.
      RETURN.
    ENDIF.

*   Editable ALV
    ls_layout-edit = 'X'.

*   Set the front layout of ALV
    CALL METHOD lo_grid->set_frontend_layout
      EXPORTING
        is_layout = ls_layout.

*   refresh the table
    CALL METHOD lo_grid->refresh_table_display.
  ENDMETHOD.                    "set_editable
ENDCLASS.                    "lcl_alv_om_tool IMPLEMENTATION

[kmoore007]

Rudolf,

If you refuse to provide the functionality which the customers want, they will continue to work around the system.  This is not un-similar to the digital music revolution in which customers wanted to buy single tracks from CDs and not the entire CD full of songs they didn't want.  The music industry tried to stop it, but they could not.  Listen to your customers!

[guillaume-hrc]

Hi,

Really like this one.
Must wait for the table to be displayed with go_alv->display( ) though, right ?

Otherwise, this code triggers a dump for the r_adapter is initial.

Using the same technique, you can select which column you want to make editable by switching the EDIT attribute of the frontend field catalog of lo_grid to 'X' WITHOUT switching the global edit with the layout).

Best regards,
Guillaume

[Former Member]

I think not the blog owner is the only one who was interested in looking behind the curtain (see here for example: http://harelgilor.blogspot.com/)

Having approx. three years experience with a SALV OBJECTS derivate framework, I dare hereby to add a stunning experience which justifies the argued statement.

If you put SALV OBJECTS related content in custom containers on a dynpro, then you try to annihilate grid data behind OO references when leaving the screen (e.g. leave to screen 0), you can observe strange things WHEN YOU RETURN and TRY TO CREATE GRID NEXT TIME. You will see ghosts of the first instance, with content which is eventually not there any more. No matter how you try to clean up when leaving a screen (be it CFW or garbage collection), some kernel level references still point to past instances on the same screen. No way to free them all - at least not for us. SALV objects is a limited framework, rather a demonstration of potential than a wannabe.

So if we want to get proper support from SAP, sadly we need to revert to traditional (and pedestrian) custom control & grid solution and bombard SAP with messages when it does not free content objects. Because we paid for it.

[naimesh_patel]

Thanks for the Explanation. SAP Should consider providing the Edit Functionality by using the SALV model.

By the way, you should at least give me some credit for using my UML diagram and doctored to suit to your application as posted on your blog.

Regards,
Naimesh Patel

[Former Member]

No, that was not me, just another interested guy I found last month, but apparently with same case application. Whether he doctored your paintings I can not judge. I appreciate efforts of you both, because I went the same way like you both but was no talented enough in painting a diagram. 🙂

I think SAP realized they missed a nice opportunity when releasing enjoy controls without unifying easy service-framework and this has gone wild. They tried to follow up many years ago with discussed results. I doubt they will update SALV OBJECTS as such (methods, attributes, heredity etc.) FUNDAMENTALLY/differently so I am not afraid of hacking my way through SAP jungle. Your approach is a feasible one. But unfortunately, if we look deeply enough behind the scenes, we have to realize that the whole sting is nothing else than a Potemkin-setup. We could believe it is nice and clean to use SALV OBJECTS then realize at complex old-fashioned hybrid screen developments (which is unavoidable under certain circumstances), that refereces behind SALV OO behave strange. Only one instance is allowed on the same screen number/container (just try to re-instantiate @ next PBO after leaving), and if you reuse a screen or use it recoursively then outdated content appears. Not tricky, just risky. Even terrible from SAP.

[naimesh_patel]

Apologies. I didn't check the name .. My bad!

[nahuelelas_romanello]

It's more complicated, but if you already have a development done with this kind of ALV classes, you can done this to edit it:

http://harelgilor.blogspot.com.ar/

[Former Member]

Naimesh,  Thanks so much for your postings on OO ALV.  They have been very helpful to me.  Now I have an issue with System Functions and ALV events.  I have a fullscreen ALV.  First thing I note, is that the SAVE button is greyed out (hmm, wonder why).  It would be nice to have.  Secondly, the Back, Exit and Cancel buttons do not respond to before and after events, and I would like that.  Have you ever tackled these issues?  Do you know how to get these buttons on the list of events?

[matt]

Coming late to this blog, I would say that Rudi Niessen's objection that "people will come to us for help" overstates the case - since when have SAP ever helped us out with custom code, which the proposed solution clearly is!?!?

btw - SAP have used a very similar solution themselves

Niamesh's new blog SALV Editable? Yes, as per this Standard SAP Application

[former_member382117]

Thanks Naimesh for the same. However, the same, I believe can be done in a more simpler and shorter way.

Let assume that I have a class inheriting from cl_salv_model and having a static method which accepts cl_salv_model and returns the controller instance as below:

class lcl_model definition inheriting from cl_salv_model.

  public section.

    class-methods: get_controller importing i_salv type ref to cl_salv_model

                                  returning value(r_controller) type ref to cl_salv_controller_model.

endclass.

class lcl_model implementation.

  method get_controller.

    r_controller = i_salv->r_controller.

  endmethod.

endclass.

I have checked with any SALV instance and it is returning me the controller proeprly.

Example call -->

data: r_salv type ref to cl_salv_table.

cl_salv_table=>factory(

              importing

                r_salv_table   = r_salv

              changing

                t_table        = <some internal table>

            ). 





data(lr_controller) = lcl_model=>get_controller( i_salv = r_salv ).

This is pretty much working. And from the controller instance, I can navigate to respective adaptor class based on the SALV display object.

 

naimesh.patel : For your comments please, if I missed anything.