Technical Articles
Handling DATA_CHANGED event in the editable SALV Grid
Because of the ease-of-use nature of CL_SALV_TABLE, we have long wanted to use CL_SALV_TABLE to handle editing as well. A post by SCN Blogger Naimesh Patel surprised many and saw potential.
https://blogs.sap.com/2015/06/25/salv-editable-with-single-custom-method/
Paul Hardy has suggested a more moderate way to make columns editable.
https://blogs.sap.com/2015/08/07/salv-and-pepper-editing-individual-columns-in-the-salv/
Even if the original design ruled out modifications, many developers wanted to, so the road was finally opened. It is known that CL_SALV_TABLE is now editable since Release 756. (See https://blogs.sap.com/2022/08/01/editable-cl_salv_table-after-release-756/)
Now that the fields are modifiable, the question here is whether you can handle up to the DATA_CHANGED event like ALV Grid does. The answer lies in the IF_SALV_GUI_OM_EDIT_RESTRICTED interface, which is important to the edit function. It is now possible to implement by specifying a listener that corresponds to an existing event handler.
See class CL_SALV_GUI_OM_EDITABLE_HNDLR for actual implementation information.
Method set_listener( ) receives an instance implementing the interface IF_SALV_GUI_OM_EDIT_STRCT_LSTR as an argument, and the interface has the following two methods.
Notice here is the method on_check_changed_data( ). We can use this method to achieve what we want.
To handle the event DATA_CHANGED, proceed as follows.
- Build editable SALV GRID
https://blogs.sap.com/2022/08/01/editable-cl_salv_table-after-release-756/
- Implement LISTENER Class
Implements two methods of interface IF_SALV_GUI_OM_EDIT_STRCT_LSTR
- Assign LISTENER
method IF_SALV_GUI_OM_EDIT_RESTRICTED~set_listener( )
1. Build editable SALV GRID
CLASS lcl_main IMPLEMENTATION.
METHOD show_salv.
select_data( ).
cl_salv_table=>factory( EXPORTING r_container = cl_gui_container=>default_screen
IMPORTING r_salv_table = mo_table
CHANGING t_table = mt_data ).
mo_table->get_display_settings( )->set_list_header( 'SALV Edit Example' ).
set_columns( ).
set_function_keys( ).
" Add custom handler method to the table (implementation details follows in the next step)
SET HANDLER handle_added_function FOR mo_table->get_event( ).
mo_edit = mo_table->extended_grid_api( )->editable_restricted( ).
mo_table->display( ).
ENDMETHOD.
...
2. Implement LISTENER Class
The LISTENER class simply implements two methods of interface IF_SALV_GUI_OM_EDIT_STRCT_LSTR. This time we will only implement the method on_check_changed_data( ).
In ALV GRID, the function supported by class CL_ALV_CHANGED_DATA_PROTOCOL, which is the reference type of ER_DATA_CHANGED parameter of event DATA_CHANGED, is divided into two interfaces, IF_SALV_GUI_OM_EDIT_UI_MODIFY and IF_SALV_GUI_OM_EDIT_UI_PROTCOL.
Interface | Main function | Method |
IF_SALV_GUI_OM_EDIT_UI_MODIFY | Function for changed data |
GET_CELL_VALUE MODIFY_CELL_VALUE GET_UI_CHANGES |
IF_SALV_GUI_OM_EDIT_UI_PROTCOL | User interface related functions such as error display |
IS_VISIBLE ADD_PROTOCOL_ENTRY DISPLAY_PROTOCOL FREE |
CLASS lcl_listener DEFINITION.
PUBLIC SECTION.
INTERFACES if_salv_gui_om_edit_strct_lstr.
ENDCLASS.
CLASS lcl_listener IMPLEMENTATION.
METHOD if_salv_gui_om_edit_strct_lstr~on_f4_request.
ENDMETHOD.
METHOD if_salv_gui_om_edit_strct_lstr~on_check_changed_data.
o_ui_data_modify->get_ui_changes( IMPORTING t_modified_cells = DATA(lt_modified) ).
DATA: seatsmax TYPE ysflight-seatsmax,
seatsocc TYPE ysflight-seatsocc.
LOOP AT lt_modified ASSIGNING FIELD-SYMBOL(<data>)
GROUP BY ( value = <data>-row_id )
INTO DATA(lt_group).
LOOP AT GROUP lt_group ASSIGNING FIELD-SYMBOL(<row_id>).
o_ui_data_modify->get_cell_value( EXPORTING row_id = <row_id>-row_id
fieldname = c_field-seatsmax
IMPORTING cell_value = seatsmax ).
o_ui_data_modify->get_cell_value( EXPORTING row_id = <row_id>-row_id
fieldname = c_field-seatsocc
IMPORTING cell_value = seatsocc ).
IF seatsmax < seatsocc.
o_ui_data_modify->modify_cell_value( row_id = <row_id>-row_id
fieldname = c_field-except
cell_value = light-red ).
DATA(error) = abap_true.
o_ui_edit_protocol->add_protocol_entry( msgid = '00'
msgty = 'E'
msgno = '001'
msgv1 = 'Line no. '
msgv2 = |{ <row_id>-row_id }|
msgv3 = ': exceeds the maximum'
fieldname = c_field-except ).
ELSE.
o_ui_data_modify->modify_cell_value( row_id = <row_id>-row_id
fieldname = c_field-except
cell_value = light-green ).
ENDIF.
ENDLOOP.
ENDLOOP.
IF error = abap_true .
o_ui_edit_protocol->add_protocol_entry( msgid = '00'
msgty = 'E'
msgno = '001'
msgv1 = 'Has Error'
msgv2 = '. Check red light(s)'
fieldname = c_field-except ).
ENDIF.
ENDMETHOD.
ENDCLASS.
3. Assign LISTENER
The method set_application_log_container( ) causes error messages to be looked up in the specified container when errors occur. If not specified, it appears as a popup as before.
mo_listener = NEW lcl_listener( ).
mo_edit->set_listener( mo_listener ).
mo_docking = NEW #( parent = cl_gui_container=>default_screen
side = cl_gui_docking_container=>dock_at_bottom
ratio = 20 ).
mo_edit->set_application_log_container( mo_docking ).
Execution
The SAVE button is not activated due to the application of display mode applied at the first execution.
If an error occurs during editing, it appears at the bottom and a red traffic light appears.
Save after error correcting.
Closing
The simplest CL_SALV_TABLE for query is now legally capable of processing modifications and validation of input information, and the system even supports CBO processing for DATA_CHAHED and ONF4 events. Now, the CL_SALV_TABLE, rather than the OO ALV(CL_GUI_ALV_GRID class) that many developers wanted, can perfectly implement the modification function. Hopefully this will help those who want to add editing to SALV in release 756 and later in the future. For older versions, see the link at the beginning of this blog.
Thank you for reading my first blog. There are many shortcomings, but I hope it helped you. If you have any questions or improvements, please feel free to leave a comment. Thank you.
Thanks.
Sorry for this little rant at your first blog post, which is nice, but the way you say it, it sounds like an official SAP announcement which I never heard... Paul Hardy would be probably happy to stop his "International Editable SALV Day". My information is based on SAP notes which say that Editable ALV Grid is not a feature supported by SAP, use it at your own risk! (I never heard of people having issues with editable CL_GUI_ALV_GRID).
Both the Editable ALV Grid and SALV are so much powerful and easy to use, that it's difficult to not use both of them combined. Concerning the strategy of custom development, I would prefer to rely on using directly the methods of both CL_GUI_ALV_GRID and CL_SALV_TABLE, rather than a third "API" which connects both but is not guaranteed to offer stability (isn't it SAP internal stuff?) and full functionality of CL_GUI_ALV_GRID (?), and requires also to learn 3 things instead of 2.
Also, I wonder why using IF_SALV_GUI_OM_EDIT* would be a better choice than the other proposed solutions.
But maybe I misunderstood all these things about IF_SALV_GUI_OM_EDIT*.
Thanks for leaving a comment.
The part you pointed out seems to have become too stiff as I wrote a blog with the help of Google Translate for my lack of English. I'll pay more attention to this.
I also think that the modification function of CL_GUI_ALV_GRID is not bad or insufficient. While displaying the data with CL_SALV_TABLE, I had to change the program to CL_GUI_ALV_GRID because of editing function. I did.
In the end, programs are also personal tastes, so one more is added to various implementation methods.
When you think about how to build the program, I hope this tip provides diversity.
For whatever reason, learning and using new features is fun. 🙂
Â
I too agree that it's nice to have diverse opinions and different ways that people can try. Thanks for that 🙂
Unfortunately, CL_SALV_TABLE is not officially editable after version 7.,56. That is the official SAP position is the editability is not supported official in CL_SALV_TABLE (or, amazingly, CL_GUI_ALV_GRID)
The blog post in question exposes what i would call an "Easter Egg" left by an internal SAP developer for their own use and not for general consumption.
Not that the technique has been mentioned on the internet I am willing to bet the loophole will be closed in the next ABAP release. i.e. CL_SALV_TABLE will not be editable again using this new technique in 7.57 or whatever.
What a surprise! Thanks for letting me know about that. It was a exciting experience to find out something that was hidden. and now i don't feel so good to hear it's gonna be unavailable later on... Anyway, It's quite an honor to get a comment from you!!
Thank you again!!