Editable CL_SALV_TABLE after release 756
Ever since the CL_SALV_TABLE class was released, one question was ever present – how to make it editable? For years the answer lied in taking advantage of the inheritance of the CL_SALV_TABLE, as presented in this post: http://zevolving.com/2008/12/salv-table-10-editable-salv-model-overcome-the-restriction-of-salv-model/.
I was among those using this method. But then the Release 756 came. And suddenly, all ALVs using it suddenly started reported error after error. I dived in and investigated the issue. To my surprise, I discovered that the very basis of this “edit-hack” was gone. The CL_SALV_TABLE class was no longer in the inheritance tree which enabled it to work!
And so followed combing through the provided interfaces in an effort to find a new way. And lo and behold! A way I indeed found.
In this post, I will share with you how I achieved CL_SALV_TABLE editable upon button-press, complete with F4 references and save function in post-release 756 environment.
New interfaces, new possibilities
The most obvious thing was the presence of several interfaces in the class. Most of them provide functionality which was previously inherited. But among them I found something curious indeed – a method called “Extendable_Grid_API( )”. On its own, the returned interface doesn’t seem all that interesting, but it provides a method for obtaining yet another interface, this one called “Editable_Restricted( )”. Now this seemed promising!
Some further digging revealed another method within this interface, the “Set_Attributes_For_Columnname( )”. And there was an option for a parameter “All_Cells_Input_Enabled”. I set it to true and eureka! My ALV was suddenly editable!
So, what is needed to make a column editable? From the CL_SALV_TABLE instance (obtained from factory as usual), get the reference from the method extendable_grid_api( ) and then from it the returning parameter from editable_restricted( ). On it, call the method set_attributes_for_columnname( ). Provide the name of the column and the parameter all_cells_input_enabled as true. And you’re done, that column is now editable!
F4 help generating
When we have editable columns, it sure is nice to also have F4 help provided as well. Fortunately, it’s quite easy. If the column type is a regular one, it’s even present right there for you from the start. Now, we often have types that are our own. For those, it is enough to add DDIC reference to the column. Just get the columns from the CL_SALV_TABLE instance (using the get_columns( ) method), from them select the relevant column using the get_column( ) method. There you can set the DDIC reference via the set_ddic_reference( ) method and you’re good to go!
Save edited values
The user put some values in the ALV and now we’d like to save them. Cl_SALV_TABLE has no check for data changed, and you’ll notice that the data table is not changed by the user inputs if you debug it. So, where do we get the new data? The answer is, in the data table. But only after we tell the system we want them there. The previously mentioned interface returned by the “editable_restricted( )” method has a method called “validate_changed_data( )”. This method returns a boolean if the changed data are valid or not. But more than that, when they are valid, it writes them in the data table we have. And we can easily access them from there (sure, we do need to check the whole data table instead of having just the changes presented, but it’s better than nothing).
And now we put it all together to achieve an ALV with button-enabled edit, F4 help and save button:
- Create CL_SALV_TABLE from factory as usual. Do note that the t_data table will be where the changed data will be. And therefore it needs to be accessible from the handler method for the save function! Add layout setting as you’re used to if you wish.
cl_salv_table=>factory( EXPORTING list_display = abap_false IMPORTING r_salv_table = o_salv CHANGING t_table = t_data ).
- Optional step for custom types: Add DDIC reference for F4 generating.
DATA lt_cols TYPE REF TO cl_salv_columns_table. DATA ls_col_grbew TYPE REF TO cl_salv_column. DATA lv_grbew TYPE lvc_fname. DATA ls_grbew_ref TYPE salv_s_ddic_reference. * Column name lv_grbew = 'YY_LE_GRBEW'. * Table name for DDIC reference ls_grbew_ref-table = 'YMAR_CT_GRBEW'. * Field in the above mentioned table for DDIC reference ls_grbew_ref-field = 'YY_LE_GRBEW'. lt_cols = o_salv->get_columns( ). ls_col_grbew = lt_cols->get_column( EXPORTING columnname = lv_grbew ). ls_col_grbew->set_ddic_reference( EXPORTING value = ls_grbew_ref ).
- After the creation of the instance, add buttons for custom functions (like EDIT and SAVE) to the CL_SALV_TABLE instance and bind the custom event handler.
DATA GR_SALV_FUNC type ref to CL_SALV_FUNCTIONS . gr_salv_func = o_salv->get_functions( ). gr_salv_func->set_all( abap_true ). * Add EDIT function gr_salv_func->add_function( name = 'YE_QM_NOTE' * Optionally add custom text and tooltip text = lv_edit_text tooltip = lv_edit_tip position = if_salv_c_function_position=>right_of_salv_functions ). * Add SAVE function gr_salv_func->add_function( name = 'YE_QM_SAVE' * Optionally add custom text and tooltip text = lv_save_text tooltip = lv_save_tip position = if_salv_c_function_position=>right_of_salv_functions ). * Add custom handler method to the table (implementation details follows in the next step) DATA(lo_events_1) = o_salv->get_event( ). SET HANDLER alv_1_on_added_function FOR lo_events_1. * Display the ALV o_salv->display( ).
- Add handler method for added functions (in my case, every ALV is an instance of a class, therefore the handler methods are set as instance methods). The handler method has the following signature: And the implementation may look similar to this:
METHOD alv_1_on_added_function. *>------------------------------------------ DATA:ls_api TYPE REF TO if_salv_gui_om_extend_grid_api, ls_edit TYPE REF TO if_salv_gui_om_edit_restricted, lv_grbew TYPE lvc_fname, lv_note TYPE lvc_fname. * ---------------------- lv_grbew = 'YY_LE_GRBEW'. lv_note = 'YY_QM_NOTE'. ls_api = gr_salv_1->extended_grid_api( ). ls_edit = ls_api->editable_restricted( ). CASE e_salv_function. * Note that the cases correspond to the names of the functions we added in step 3) WHEN 'YE_QM_NOTE'. * Code for edit enabling goes here - implementation follows in step 5) WHEN 'YE_QM_SAVE'. * Code for save goes here - implementation follows in step 6) WHEN OTHERS. * Do nothing ENDCASE. ENDMETHOD.
- Implementation of the EDIT case – turned on or off for given columns. The instance of the ALV has an attribute signalling whether or not editing is currently on.
IF gv_edit = ''. gv_edit = 'X'. ELSE. gv_edit = ''. ENDIF. IF gv_edit = 'X'. TRY. * Enable editing ls_edit->set_attributes_for_columnname( EXPORTING columnname = lv_grbew all_cells_input_enabled = abap_true ). ls_edit->set_attributes_for_columnname( EXPORTING columnname = lv_note all_cells_input_enabled = abap_true ). CATCH cx_salv_not_found. ENDTRY. ELSE. TRY. * Disable editing ls_edit->set_attributes_for_columnname( EXPORTING columnname = lv_grbew all_cells_input_enabled = abap_false ). ls_edit->set_attributes_for_columnname( EXPORTING columnname = lv_note all_cells_input_enabled = abap_false ). CATCH cx_salv_not_found. ENDTRY. * When editing is turned off, the user input is checked and data table updated ls_edit->validate_changed_data( ). o_salv->refresh( ). ENDIF.
- Implementation of the SAVE case
TRY. ls_edit->validate_changed_data( IMPORTING is_input_data_valid = DATA(s) ). o_salv->refresh( ). CATCH cx_salv_not_found. ENDTRY. * Input is valid, we can save the data IF s = 'X'. * You will need to implement your own save method, based on your own data save( ). ENDIF.
And this is it! The removal of inheritance from CL_SALV_TABLE may have broken one method of enabling editing, but fortunately another one was made possible. Once again, this is only possible from release 756 onwards. The previous releases still contain the inheritance and therefore editing can be done by the method described in the method linked at the beginning.
I hope this may be useful to those, whose programs suddenly stopped working after an update. Or perhaps to those looking to now implement editable CL_SALV_TABLE in a new release.
Good work, Michaela. Thanks a lot.
Very Informative , Thank you Michaela Horvathova
Thank you so much for this informative blog
Great work. Really.
Paul Hardy - I think you might like this.
In fact it's Paul Hardy
expecting his reaction...
It's great blog,Thanks.
This is a very good blog. I it is OK with you I would like to add a reference to this blog in the next edition of my ABAP to the Future book to give credit where it is due, as I will have to change the chapter to consider the difference between pre and post ABAP 7.56
The bad news for me is that I have access to two SAP systems - an S/4HANA on-premise one which is at ABAP 7.55 so does not have the change above, and an ABAP in the Cloud system which does not have the SAP GUI of course. thought I imagine it will have the changes to CL_SALV_TABLE described above even if the class it not whitelisted so I can investigate the underlying code.
To be honest when my mate Jim alerted me to this blog I was hoping it was an official blog written by someone from SAP who was going to finally admit that CL_SALV_TABLE should have been editable from the start and here is the official solution.
Instead it seems more like
Naturally I will also be adding a reference to this blog in next February's "International Editable SALV Day" blog, as I am not going to rest until this functionality is supported by SAP to at least functional parity with CL_GUI_ALV_GRID e.g. you can make individual cells editable based on business logic.
I am highly honoured that you think this post good. I have gotten so much knowledge from all your works! If you wish to include a reference to this anywhere, feel free to do so.
Additionally, I have tried this new class with container and splitters and it works totally fine without any major modifications.
As for official reasonings - I have found this comment in the new interface:
""! This interface is a restricted edit wrapper for SALV OM in edit mode starting with SAP release 756.
"! It wraps the editable part of the ALV grid (cl_gui_alv_grid), which is responsible
"! for modifying cells (either through manual editing or using F4 help). The functionality
"! of copying, deleting, inserting or appending of rows at the frontend will not be covered.
"! As stated in SAP note #695910 and in the ALV grid documentation, the editable functions
"! and the corresponding methods/attributes of the ALV grid are not released, therefore
"! this interface is also not released and was only designed for compatibility reasons.
"! It is designed to help three SAP applications, which have not only used the official API
"! but internal ALV artifacts and they have signed to comply with the internal restrictions
"! related to the edit mode.
"! The affected applications have been added to the PIF IF_SALV_OM_EXT_API.
This was all the info I was able to find on this whole change, which I found a bit sad, considering how majorly it can break the programs relying on the class hierarchy.
Thanks for this very helpful blog!
We implemented this in our system and it saved a lot of our applications based on this feature from not working anymore.
I found one issue which is a litte odd. If I have an ALV with just a small number of lines, switching to edit mode works fine. But if the ALV has a lot of lines (e.g. 1000), the switch to edit mode is not working anymore. With the old method pre 7.56 this was no problem (even for much more lines).
Does anybody else also encounter this issue? Does anybody have a solution for it?
I thought the number of lines where it does not work anymore is maybe the paging limit, but I tried that and it is not true (it works also with more lines than the paging limit).
Also setting a filter does not help. This means if I show 1000 lines first, set a filter to only show 1 and than try to edit, it does not work. But if I show only this one line from the beginning, it does work.
Even if you do not have a solution for that, it would really help me if some of you can check if you have the same issue. This would help me to understand if this is a gerneral problem or if this is a specific problem of my implementation or system environment (maybe SAPGUI version?).
I have same problem.
Could you find the solution for issue?
I mentioned some thing like this below in order to read 3 decimals for the input field
In the field catalogue for DECIMALS property mentioned 3 so it is able to read 3 decimals
and also make it as editable so that it allows to input value
After making these changes call the check_changed_data method for the classs cl_gui_alv_grid then you can able to get the right value with decimals
Remaining functionality similar based on your requirement
Sorry I do not understand how this is related to the described error. Can you please describe your solution a littel bit more in detail?
no I did not find a solution yet.
I don't want to say that I'm happy that you also have that error, but at least it seems to be some gerneral error and no problem with my implementation (I don't know if this is really a good thing).
I will post here if I find a solution. Does somebody else also have this issue?
Though this blog contains code for each functionality wise but still some part of the code is missing. Where can we get the full length of code??
Am getting error while for event handler. Where it is defined??
What are the steps need to be done to get screen defined in step 4
Thx! Really helpful and safes plenty of time!
I've recently come across a program using SALV, with editable columns, but now the users want only certain rows to be editable. Prior to release 756, was there a way to do this? It would imply adding a field of type LVC_T_STYL to the grid table but this dumps in Form FILL_DATA_TABLE of program SAPLSLVC with the following message:
I don't say it is impossible but I spent hours in debugging to find a solution for that problem and I was never able to find a way 🙁
I hope you are more successful than me!
Thanks for your answer.
I am surprised people keep using SALV. I mean, standard ALV is not that much more complicated. Might as well use the most complete of the two in case we have to add functionalities in the future.
Anyway, my two cents...
Is it possible to post a complete sample SALV program using the above code. Thanks
Sorry for the sad news. but the standard code ( version 7.57 on our system ) sets a limit of 5000 visible CELLS to enable or not the editable "unreleased feature" on the SALV grid. ( beyond 5000 cells the SALV will not be editable )
This check is in method CL_SALV_GUI_OM_ADAPTER_TABLE->CAN_RUN_RESTRICTED_EDIT_MODE , called inside the CL_SALV_GUI_OM_ADPT_GRID->if_salv_adapter~set_metadata
The constant name is CV_MAX_CELLS_FOR_EDITABLE ( value = 5000 ).
That's why it does not work when your SALV reaches this limit of cells.