Skip to Content
Technical Articles
Author's profile photo Michaela Horvathova

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:

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!

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

Step-by-step guide
And now we put it all together to achieve an ALV with button-enabled edit, F4 help and save button:

  1. 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.
                 list_display = abap_false
                 r_salv_table = o_salv
                 t_table      = t_data ). 
  2. 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(
    		          columnname = lv_grbew
    		          value = ls_grbew_ref
  3. 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.
    	gr_salv_func = o_salv->get_functions( ).
    	gr_salv_func->set_all( abap_true ). 
    	* Add EDIT 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
    	            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( ).
  4.  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:Handler%20method%20signatureParameter%20of%20the%20handler%20methods 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
  5. 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'.
    	        gv_edit = ''.
    	      IF gv_edit = 'X'.
    	* Enable editing
    	              columnname = lv_grbew
    	              all_cells_input_enabled = abap_true
    	              columnname = lv_note
    	              all_cells_input_enabled = abap_true
    	          CATCH cx_salv_not_found.
    	* Disable editing
    	                columnname = lv_grbew
    	                all_cells_input_enabled = abap_false
    	              columnname = lv_note
    	              all_cells_input_enabled = abap_false
    	          CATCH cx_salv_not_found.
    	* When editing is turned off, the user input is checked and data table updated
    	        o_salv->refresh( ).
  6. Implementation of the SAVE case
    	            is_input_data_valid = DATA(s)
    	          o_salv->refresh( ).
    	        CATCH cx_salv_not_found.
    	* 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( ).

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Ladislav Horvath
      Ladislav Horvath

      Good work, Michaela. Thanks a lot.

      Author's profile photo Chithra Narayanan
      Chithra Narayanan

      Very Informative , Thank you Michaela Horvathova

      Author's profile photo Wises Keshom
      Wises Keshom

      Thank you so much for this informative blog

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Great work. Really.

      Paul Hardy - I think you might like this.

      Author's profile photo Jose Muñoz Herrera
      Jose Muñoz Herrera

      In fact it's Paul Hardy

      expecting his reaction...

      Author's profile photo Tao Wang
      Tao Wang

      It's great blog,Thanks.

      Author's profile photo Paul Hardy
      Paul Hardy

      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

      • SAP developers discovered the back door to making CL_SALV editable by looking at blogs and such and closed it off, as has happened several times previously.
      • Interestingly this time they added a new  unofficial "back door" or "Easter egg" or whatever you want to call it, and presumably hoped no-one would discover it.
      • Also interestingly from the above code it seems that adding new custom functions in CL_SALV_TABLE has become less problematic. Before the class reacted very differently based on whether you had a custom screen with a container, or just used the FACTORY and DISPLAY methods without defining a custom screen.

      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.

      Cheersy Cheers


      Author's profile photo Michaela Horvathova
      Michaela Horvathova
      Blog Post Author

      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.


      Best regards,


      Author's profile photo Christoph Paulusch
      Christoph Paulusch

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


      Author's profile photo Umit Durus
      Umit Durus


      I have same problem.

      Could you find the solution for issue?




      Author's profile photo vykuntarao tangudu
      vykuntarao tangudu

      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



      Author's profile photo Christoph Paulusch
      Christoph Paulusch

      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?


      Author's profile photo Christoph Paulusch
      Christoph Paulusch

      Hu Umit,

      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?


      Author's profile photo vykuntarao tangudu
      vykuntarao tangudu

      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??

      Author's profile photo vykuntarao tangudu
      vykuntarao tangudu

      What are the steps need to be done to get screen defined in step 4

      Author's profile photo Rolf Manzke
      Rolf Manzke

      Thx! Really helpful and safes plenty of time!

      Author's profile photo Patrice Poirier
      Patrice Poirier

      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:

      You attempted to move one data object to another.
      This is not possible here because the conversion of a data object
      of type "h" to type "g" is not supported.

      Author's profile photo Christoph Paulusch
      Christoph Paulusch

      Hi Patrice,

      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!


      Author's profile photo Patrice Poirier
      Patrice Poirier

      Hi Christoph,

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

      Thanks again.

      Author's profile photo Steve Swaby
      Steve Swaby

      Is it possible to post a complete sample SALV program using the above code.  Thanks


      Author's profile photo thomas bricout
      thomas bricout


      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.

      Author's profile photo Gauthier Egot
      Gauthier Egot

      Thank you for this very informative post, this is wonderful both to know that SAP takes developpers requirement into account, and that there are people sharing their knowledge for such important matter ! It will surely improve day-to-day life of a lot of ABAP developpers.

      Sadly,my system's company has not been upgraded to 756 yet, which means it will take days of work instead of 20 minutes to switch from my non-editable to editable alv, this is depressing 😞

      Author's profile photo Luis Andres Lara Graffe
      Luis Andres Lara Graffe

      Hi Michaela.


      Great Post, sorry one question, how did you achieve the checkboxes in the first column of your report using the  CL_SALV_TABLE. I'm new to using this ALV Class. Thanks

      Author's profile photo Raghavendra Raghavendra
      Raghavendra Raghavendra

      Hi Michaela,


      what is the value of

      Author's profile photo Benedikt Schneiber
      Benedikt Schneiber

      Hi fellow ABAPers!

      Has anybody managed to get the ALV toolbar added as soon as the "input readiness" is turned on via the new tricks mentioned in this (great!!!) blog post?


      I could add the needed functions to the general SALV status and handle those via the e_salv_function handler, that's clear - but it would be nice to be able to use the default functionality here instead of adding them manually.


      For reference, here's my first try of the new trick, which yields the result shown in above screenshot (left side):