Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
uwe_schieferstein
Active Contributor

Introduction

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.

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).  

 

Summary

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).

 

 

 

Appendix

(A) Report ZUS_SDN_TWO_ALV_GRIDS

 

 

(B) Report ZUS_SDN_TWO_SALV_GRIDS

19 Comments
andrea_olivieri
Contributor
0 Kudos
Hi Uwe,
Thanks for the effort.
After reading this post we learned something new.
Again, great blog!

Regards
Andrea
SuhaSaha
Advisor
Advisor
0 Kudos
I thought Naimesh was the ALV guru. I have added Uwe to this list as well.

Anyway Uwe very educational blog. Thanks for enlightening me.

BR,
Suhas
uwe_schieferstein
Active Contributor
0 Kudos
Hello Suhas

Thank you for this compliment.
Actually, we there are three of us:
Naimesh, Marcin (Pciak), and me.

Regards
  Uwe
Former Member
0 Kudos
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 ?
MarcinPciak
Active Contributor
0 Kudos
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:)

Cheers
Marcin
SuhaSaha
Advisor
Advisor
0 Kudos
"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.

Cheers,
Suhas
SuhaSaha
Advisor
Advisor
0 Kudos
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.

Cheers,
Suhas
uwe_schieferstein
Active Contributor
0 Kudos
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.

Regards
  Uwe
Former Member
0 Kudos
Thanks Uwe & Suhas.

Regards
Vinod
madhu_vadlamani
Active Contributor
0 Kudos
Hi,
Perfect example.Thanks for giving a good blog with an example.
Regards,
Madhu.
Former Member
0 Kudos
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. 
Thanks.
Former Member
0 Kudos
I thought we can edit the field in cl_salve

lo_item = lo_node->get_item( 'xxx' ).     
lo_item->set_editable( abap_true ).

Is this correct?
uwe_schieferstein
Active Contributor
0 Kudos

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

Former Member
0 Kudos
I replaced the change_data routine, run it and got run time error
OBJECTS_OBJREF_NOT_ASSIGNED   
CX_SY_REF_IS_INITIAL          
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.                      
ENDTRY.                                   
Former Member
0 Kudos
Sorry, I got it.  I selected the whole line and it does not work.
Thanks,
Former Member
0 Kudos
Sorry, I got it.  I selected the whole line and it does not work.
Thanks,
uwe_schieferstein
Active Contributor
0 Kudos
Hello Valerie

Using tree controls you always have to take care of both options:
- select node (presumably entire line)
- select item (in tree part)

It is always motivating to see that my sample coding can be applied to real world problems.

Regards
  Uwe
Former Member
0 Kudos
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?
uwe_schieferstein
Active Contributor
0 Kudos
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.

Regards
   Uwe