Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

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


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.



Editable CL_SALV_TABLE


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.
    cl_salv_table=>factory(
    EXPORTING
    list_display = abap_false
    IMPORTING
    r_salv_table = o_salv
    CHANGING
    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(
    EXPORTING
    columnname = lv_grbew
    ).
    ls_col_grbew->set_ddic_reference(
    EXPORTING
    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.
    	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( ).


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


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


  6. 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.
30 Comments
rohadal
Explorer
Good work, Michaela. Thanks a lot.
ChithraN
Explorer
Very Informative , Thank you michaelahorvathova
bztoy
Participant
Thank you so much for this informative blog
matt
Active Contributor
Great work. Really.

bfeeb8ed7fa64a7d95efc21f74a8c135 - I think you might like this.
tao-wang
Participant
It's great blog,Thanks.
JoseMunoz
Active Participant
In fact it's bfeeb8ed7fa64a7d95efc21f74a8c135

expecting his reaction...
hardyp180
Active Contributor
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

Paul
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,

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

Thanks,
Christoph
vykuntrao
Participant
0 Kudos
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??
alv_1_on_added_function
vykuntrao
Participant
0 Kudos
What are the steps need to be done to get screen defined in step 4
rom_abat
Member
0 Kudos
Thx! Really helpful and safes plenty of time!
umitdurus
Discoverer

Hello,

I have same problem.

Could you find the solution for issue?

Thanks.

 

 

vykuntrao
Participant
0 Kudos
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

Thanks

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

Best,
Christoph
0 Kudos
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?

Thanks,
Christoph
Patrice
Participant
0 Kudos
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.
former_member630841
Discoverer
0 Kudos
Is it possible to post a complete sample SALV program using the above code.  Thanks

 
0 Kudos
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!

Best,
Christoph
tomboolean
Discoverer

Hello,

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.

Patrice
Participant
0 Kudos
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.
gauthier_egot
Explorer
0 Kudos
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 😞
luislara76
Explorer
0 Kudos
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

vasiraghavendra
Explorer
0 Kudos
Hi Michaela,

 

what is the value of
lv_save_tip

lv_save_text

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):

 

Mehh
Participant
0 Kudos
Hello,

 

Very interesting blog.

 

I have one question for those of you who've implemented above solution: Does it also work in the WEBGUI? We've upgrade a customer from S/4HANA 1809 to S/4HANA 2023 FP01. First the SALV was no longer editable in the SAP GUI, I fixed that with above code (many thanks Michaela). Now we encounter an interesting (but frustrating) issue in the WEBGUI: An exception in the kernel (yes kernel) after changing the content of an editable cell and moving the cursor to another cell.

 

:D

 

regards,
HFumey
Explorer
0 Kudos
Great Information in this blog. I am sure it will come in handy working on an 756 or later realase.

I find that the SALV model and Webgui has other "quirks" too. Try displaying an SALV that works in a  split-screen in SAPGUI within the Webgui. If someone got that working, let me know.

Thanks

Harry
rajib3301
Discoverer
0 Kudos


 

I have followed each step mentioned above. Absolutely working fine for small data set but for large data set Adjusted Discount Amount showing like mentioned screenshot and it is not updating
ekekakos
Participant
0 Kudos

Hello and thanks. But I have a problem with this. It enables for editing a column only if the ALV has 227 rows. If it has 228 the column is remaining in disable mode for editing.

Does anyone has faced this problem?

Thanks in advance,

Elias

matt
Active Contributor
0 Kudos

Given as how SAP are determined to disallow this, I think it's unstable to rely on the workarounds - although they are fun - in a production environment. Use CL_GUI_ALV_TABLE instead. It's really not that difficult and rather more stable across releases.