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:
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).
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).
(A) Report ZUS_SDN_TWO_ALV_GRIDS
(B) Report ZUS_SDN_TWO_SALV_GRIDS