Problem with double editable ALV GRID refresh

[dario_fiorillo49]

Hello,
I'm having a problem with a dynpro containing two editable ALV GRIDs when I refresh them after editing a cell.
I am using CL_GUI_ALV_GRID with two containers (header and item) in the same dynpro and I am calling the method register_edit_event with mc_evt_modified and mv_evt_enter for both go_alv_0101_h (header) and go_alv_0101_i (item).

This is the problem: if I enter a value in/modify a cell of the header ALV and then I press ENTER or click on another cell of the same ALV, the method handle_data_changed is triggered and the value is kept (this is OK), while if I enter a value in/modify a cell on the header ALV (without pressing enter or clicking on a cell of the same ALV) and then I click on the item ALV, handle_data_changed is not triggered and if I modify one cell on the item ALV, the new value I entered in the header ALV is lost (the cell returns blank or has the old value).

Same problem if a enter a value in the item ALV and soon after I click on a cell of the header ALV and modify one of its cells.

Is there a way to trigger handle_data_change when I enter a value in the first ALV and soon after I click on a cell of the second ALV?

Thank you

[xiswanto]

Correct me if I'm wrong, In my opinion, it is the ALV default behavior to trigger the data changed method and so far I haven't found other method that could be used to triggered if we do action outside of the ALV area.

[Sandra_Rossi]

I don't reproduce your issue. On the left, in the first line I type URL = anything, click on right, in the first line I type CONNID = any number, then press F8, it displays the values I have typed. ABAP 7.57, SAP GUI 7.70 SP 0.

REPORT zdemo.
DATA go_splitter_container TYPE REF TO cl_gui_splitter_container.
DATA go_container_left TYPE REF TO cl_gui_container.
DATA go_container_right TYPE REF TO cl_gui_container.
DATA go_alv_left TYPE REF TO cl_gui_alv_grid.
DATA go_alv_right TYPE REF TO cl_gui_alv_grid.
DATA gt_scarr TYPE TABLE OF scarr.
DATA gt_spfli TYPE TABLE OF spfli.
TABLES sscrfields.
PARAMETERS dummy.
AT SELECTION-SCREEN OUTPUT.
  IF go_splitter_container IS NOT BOUND.
    CREATE OBJECT go_splitter_container
      EXPORTING
        parent  = cl_gui_container=>screen0
        rows    = 1
        columns = 2.
    go_container_left = go_splitter_container->get_container( row = 1 column = 1 ).
    go_container_right = go_splitter_container->get_container( row = 1 column = 2 ).
    SELECT * FROM scarr INTO TABLE gt_scarr.
    SELECT * FROM spfli INTO TABLE gt_spfli.
    CREATE OBJECT go_alv_left
      EXPORTING
        i_parent = go_container_left.
    go_alv_left->set_table_for_first_display(
        EXPORTING
          i_structure_name = 'SCARR'
          is_layout        = VALUE #( edit = 'X' )
        CHANGING
          it_outtab        = gt_scarr ).
    CREATE OBJECT go_alv_right
      EXPORTING
        i_parent = go_container_right.
    go_alv_right->set_table_for_first_display(
        EXPORTING
          i_structure_name = 'SPFLI'
          is_layout        = VALUE #( edit = 'X' )
        CHANGING
          it_outtab        = gt_spfli ).
  ENDIF.
AT SELECTION-SCREEN.
  IF sscrfields-ucomm = 'ONLI'.
    go_alv_left->check_changed_data( ). " <=== transfer from screen to GT_SCARR
    go_alv_right->check_changed_data( ). " <=== transfer from screen to GT_SPFLI
    MESSAGE |{ VALUE #( gt_scarr[ 1 ]-url OPTIONAL ) } - { VALUE #( gt_spfli[ 1 ]-connid OPTIONAL ) }| TYPE 'I'.
    sscrfields-ucomm = VALUE #( ).
  ENDIF.

[dario_fiorillo49]

Thank you Sandra,
but I am not using cl_gui_splitter_container. I have defined 2 different containers in the dynpro layout, one on top of the screen and the other on bottom.

[Sandra_Rossi]

I don't see why it would behave differently whatever the type of container is, and whatever the position is on the left, right, top or bottom.

I just tried (took me 2 minutes to adapt), and I confirm that it works fine for me too.

So, if you want to continue discussing, just try the program above. If it works fine for you, it means that your program has a bug, otherwise, it's a difference due to the ABAP or SAP GUI version, I can't help more, you must then check SAP notes, or install latest SAP GUI version, or install a more recent ABAP version.

[xiswanto]

Perhaps in the dalfi case, he is not doing any action button ( which in your case, you are using the default =ONLI ) button to update both itab, but instead, he is seeking for event which could be triggered if the active cursor leaves from the OO ALV which is changed a moment ago( which will trigger the inline declared method to update respective itab based on which OO ALV event is triggered ), since the data_changed event he is currently using is not triggered when the cursor changed from first OO ALV into second OO ALV.

*usually we triggered the data_changed custom inline method by pressing enter after changing the field value we wanted, right?

[Sandra_Rossi]

xiswanto No, I adapted my code to reflect dalfi case ("took me 2 minutes to adapt" = dynpro + custom controls vertically positioned, GUI status and button in application toolbar), it behaves exactly same as with my short code above.

Of course, I didn't indicate everything of Dario scenario, but I think that Dario would better post a minimal reproducible example (= few lines of code) so that people can easily test and answer/fix the issue (the same way as I did, anybody can test immediately/no time lost in hypothetical and hazardous assumptions).