Skip to Content

Against All Odds – Programming of Communicating (S)ALV Grid Controls


Quite often developers struggle with the communication between ALV grid instances. As soon as a record is selected in the “main” ALV list the details for this records should be displayed in the “detail” ALV list (e.g. Customer -> SalesAreas). Whereas the first double-click event works as expected quite frequently the second event fails, e.g. threads:

CALL METHOD ob_grid1->set_table_for_first_display does not change display

Problem with Custom container ->cl_gui_custom_container/cl_gui_alv_grid

Text edioter in Pop up window

Can I use Docking container in Subscreen


In the past I answered such questions several times but even I have problems to recover my own sample reports from SDN. Therefore, I document this solution a last time in this blog and I show that there is almost no difference whether the two communicating (S)ALV grids are displayed on the same screen, on 2 different main screens or even in a popup.  


(1) Example: Both ALV Lists Displayed in Same Main Screen

Below you see the (single) main screen showing the ALV list containing customer records.

Communicating ALV Grids: Initial State

As soon as the user double-clicks on a record the details (Salesareas of the customer) are displayed in the second ALV list. For displaying the two ALV grids together on the same screen a splitter container is used.


Double-clicking on a different customer row automatically refreshes the the second ALV grid. 



(2) Each ALV List Displayed on Different Main Screen (not shown)

In this case each grid instance is displayed using a separate docking container.


(3) Detailed ALV List Displayed on Popup Screen

As soon as the user double-clicks on a record the details (Salesareas of the customer) are displayed in a popup.



Screens – Keep It Simple and Stupid

Provided that the ALV lists are the only elements displayed on the screens we can keep them quite simple: basic flow logic and NO elements (not even a custom control because it is not required)!





NOTE: The sample report ZUS_SDN_TWO_ALV_GRIDS contains 3 screens (0100, 0200, 0205). The flow logic of all 3 (empty) screens is described in the documenation header of the report (see Appendix: report ZUS_SDN_TWO_ALV_GRIDS).


Initialize & Display Controls Before Calling any Screen

Even though virtually all sample reports (BCALV_…) of SAP show the creation and display of controls (container, grid, tree) within the flow logic of the displaying this is not mandatory. On the contrary, I prefer to do the entire control initialization BEFORE calling any screen. Below you see the START-OF-SELECTION section of my sample report. Within routine INIT_CONTROLS all container and grid instances are created. In addition, I even call method SET_TABLE_FOR_FIRST_DISPLAY within this routine.

As next step I link the main ALV list (parent container = GO_DOCKING) to the target screen ‘0100’. Eventually, the main screen is called.



What is the advantage of this approach? Well, if you want to display the ALV list on another screen of your application then just do it – by calling again the LINK method of the container.


Displaying ALV Grid in Main Screen vs. Popup – So What?

The only difference is the dynpro level:


Leave the Event Handler and Trigger PAI

The advantage of this approach is that you always end up with a clearly defined status. After handling the user-command at PAI the flow moves on to PBO at which flushing of the controls occurs by default.


Classic vs. New ALV Object Model – Nothing Special

Regarding the different modes of displaying ALV lists there is no difference whether you are using class CL_GUI_ALV_GRID or CL_SALV_TABLE because the LINK method belongs to the container controls and not to the grid controls (see Appendix: report ZUS_SDN_TWO_SALV_GRIDS).  



Communicating ALV grids is a standard ABAP development task which is not complicated by different modes of displaying the ALV lists. 

The approach described here can be adapted for any kind of communicating controls (e.g. tree & grid).









You must be Logged on to comment or reply to a post.
        • Hi Uwe,

          It's nice you have refreshed this topic. It seems lots of people are confused about ALV programming if only several controls are included. This will be a nice one to give as a reference to everyone who struggle with multiple ALV-related issues. Thanks for that.

          BTW: It seems I have been given a label I am not aware of 😉 Will not complain too much about it, however Guru is the level I can just dream of. Anyway it's a pleasure to see my name next to yours Guys:)


          • "Will not complain too much about it, however Guru is the level I can just dream ofWill not complain too much about it, however Guru is the level I can just dream of"

            This applies to me buddy. FYI i've started applying Uwe's technique already 😉

            Sure a few people would get confused with the K.I.S.S principle Uwe has mentioned in this blog.


  • Great Blog. I Was searching for something like this. Thanks for sharing the information.  One Question Uwe, Can we create similiar reports using SALV classes ?
    • Hello Vinod,

      Let me answer this. I'm sure you might be aware of this: SALV & BCALV techniques cater similar functionalities, but the implementation techniques are different.

      Only exception(and this is a major difference) is that in SALV doesn't allow the "Editable Grid" functionality.


    • Hello Vinod

      I have added a second sample report using class CL_SALV_TABLE. As you can see from the coding there is virtually no difference between these two ALV grid models with respect to the displaying modes.


  • Great blog.  Can this apply to cl_salv_tree?
    I have a requirement to 1) create customer hierarchy tree report. 2) If user select the tree nodes and click button to block or unblock customer sales area. It should first pop up screen to ask some info, take that info to update some Z tables behind the scene and then block or unblock all low level customers in the selected node(s) (this is multi selection) and then show updated data on screen.
    I was able to finish the first part and struggle in the second part.  There is sample salv_demo_data_update but it does not have the popup screen to get some info. 
    • Hello Valerie... §5.3 add a new node to the second node<br/>  TRY.<br/> find the nodes where the data should be changed * and change the data<br/><br/>**    nodes = gr_tree->get_nodes( ).<br/>*<br/>*    node1 = nodes->get_top_node( ).*<br/>*    node1 = node1->get_first_child( ).*<br/>*    node1->expand( ).ENDFORM.                    " change_data

      • I replaced the change_data routine, run it and got run time error
        01/18/2011 16:51:55  
           lo_selections = gr_tree->get_selections(
            lo_item       =                         
             lo_selections->get_selected_item( ).
        It stops here, lo_item is always initial.
        >> lo_node       = lo_item->get_node( ).   
        t_node        = lo_node->get_children( ).
          t_node        = lo_node->get_subtree( ).
        CATCH cx_salv_msg.                      
  • I tried to implement this approach, but when I refresh the first ALV data and call the screen 100, the first screen stays the same despite my attempt to flush or use the refresh method. Any suggestion?
    • Hello Anatoliy

      When you want to refresh an ALV list always ensure that you pass PAI followed by PBO. Probably it is a good idea to place the method call go_grid->REFRESH_TABLE_DISPLAY( ) at PBO.