Skip to Content
Author's profile photo Naimesh Patel

SALV Editable? Yes, as per this Standard SAP Application

Don’t get too excited about the editable SALV solution out of the box, but I think we have a solution.

Recently Paul Hardy published a blog International Editable SALV day as the 8th anniversary of the first SALV Editable question and so far no out of the box solution. To those who hasn’t read the previous so many discussion, out of box solution means a single method to make it editable. As of ABAP 740 SP05, there isn’t any new method in SALV OM which does the same thing or at least sounds like SET_EDITABLE.

I developed an work around in November 2008 and got lot of criticism for that. You can see the solution and read the comments – Power of ABAP Objects: Overcome the Restrictions of SALV Model

Based on the comments, customers should never use these type of workarounds. Obviously,  SAP must not use the work around as they say Editable is not intended purpose of SALV OM. But, look what I found >> Standard SAP (yes, standard SAP) has used the almost similar approach to make SALV editable which I used in my solution.

Standard SAP Application

I was replying to some query on CL_SALV_TREE and I did a where used on the adapter object and stumbled upon this function group FOT_RFD_MONI. Usually the adapter is used by only CL_SALV* Classes and my test program. But, suddenly I see a new program popping up in the where used list and that kept me thinking what is this program doing here?

This standard SAP application is developed using this approach – almost same as the approach used in my solution. (Note, that I’m not calling it a workaround anymore 😉 ):

  • Inherit the class from the Model class
  • Create a method in the inherited class to gain access to the Adapter object – E.g. Grid, Fullscreen, Tree
  • Gain access of the underlying object – Grid or Tree

Class definition

Std_SAP_SALV_Editable_1_000.png

Class Implementation

Std_SAP_SALV_Editable_1_001.png

Use of method to make Grid editable / non-editable

Std_SAP_SALV_Editable_2_000.png

Std_SAP_SALV_Editable_2.png

Redefined Solution

So, based on this design, I simplified my version of the approach. Created a custom class where I have couple of helper methods to gain access to the adapter and then the underlying object – either Grid or Tree.

  • GET_GRID would be used to get the CL_GUI_ALV_GRID object
  • GET_TREE would be used to get the CL_GUI_ALV_TREE object

Utility Class

*———————————————————————-*
*       CLASS ZCL_TEST_NP_SALV_MODEL DEFINITION
*———————————————————————-*
*
*———————————————————————-*
CLASS zcl_test_np_salv_model DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    CLASS-METHODS get_grid
      IMPORTING
        !io_salv_model TYPE REF TO cl_salv_model
      RETURNING
        value(eo_grid) TYPE REF TO cl_gui_alv_grid
      RAISING
        cx_salv_error .
    CLASS-METHODS get_tree
      IMPORTING
        !io_salv_model TYPE REF TO cl_salv_model
      RETURNING
        value(ro_tree) TYPE REF TO cl_gui_alv_tree
      RAISING
        cx_salv_error .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS ZCL_TEST_NP_SALV_MODEL IMPLEMENTATION.

* <SIGNATURE>—————————————————————————————+
* | Static Public Method ZCL_TEST_NP_SALV_MODEL=>GET_GRID
* +————————————————————————————————-+
* | [—>] IO_SALV_MODEL                  TYPE REF TO CL_SALV_MODEL
* | [<-()] EO_GRID                        TYPE REF TO CL_GUI_ALV_GRID
* | [!CX!] CX_SALV_ERROR
* +————————————————————————————–</SIGNATURE>
  METHOD get_grid.

    DATAlo_error      TYPE REF TO cx_salv_msg.

    IF io_salv_model->model NE if_salv_c_model=>table.
      RAISE EXCEPTION TYPE cx_salv_msg
        EXPORTING
          msgid = ’00’
          msgno = ‘001’
          msgty = ‘E’
          msgv1 = ‘Incorrect SALV Type’.
    ENDIF.

    eo_grid = lcl_salv_model_list=>get_grid( io_salv_model ).

  ENDMETHOD.                    “get_grid

* <SIGNATURE>—————————————————————————————+
* | Static Public Method ZCL_TEST_NP_SALV_MODEL=>GET_TREE
* +————————————————————————————————-+
* | [—>] IO_SALV_MODEL                  TYPE REF TO CL_SALV_MODEL
* | [<-()] RO_TREE                        TYPE REF TO CL_GUI_ALV_TREE
* | [!CX!] CX_SALV_ERROR
* +————————————————————————————–</SIGNATURE>
  METHOD get_tree.

    DATAlo_error      TYPE REF TO cx_salv_msg.

    IF io_salv_model->model NE if_salv_c_model=>tree.
      RAISE EXCEPTION TYPE cx_salv_msg
        EXPORTING
          msgid = ’00’
          msgno = ‘001’
          msgty = ‘E’
          msgv1 = ‘Incorrect SALV Type’.
    ENDIF.

    ro_tree = lcl_salv_model_list=>get_tree( io_salv_model ).

  ENDMETHOD.                    “GET_TREE
ENDCLASS.

To get the CL_GUI_ALV_GRID:

    DATA: lo_grid   TYPE REF TO cl_gui_alv_grid.
    DATA: lo_msg    TYPE REF TO cx_salv_msg.
    TRY .
        lo_grid  = zcl_test_np_salv_model=>get_grid( o_salv ).
      CATCH cx_salv_msg INTO lo_msg.
        “appropriate handling
    ENDTRY.

Local class LCL_SALV_MODEL_LIST which is inherited from CL_SALV_MODEL_BASE. Previously, I used the CL_SALV_MODEL_LIST to inherit my helper class, which wouldn’t provide me the instance for the TREE. Thus, moved higher in the class hierarchy.

*”* use this source file for the definition and implementation of
*”* local helper classes, interface definitions and type
*”* declarations

*
CLASS lcl_salv_model_list DEFINITION INHERITING FROM cl_salv_model_base.

  PUBLIC SECTION.

    CLASS-METHODS:
      get_grid
        IMPORTING
          io_salv_model TYPE REF TO cl_salv_model
        RETURNING
          value(ro_gui_alv_grid) TYPE REF TO cl_gui_alv_grid
        RAISING
          cx_salv_msg,

      get_tree
        IMPORTING
          io_salv_model TYPE REF TO cl_salv_model
        RETURNING
          value(ro_tree) TYPE REF TO cl_gui_alv_tree
        RAISING
          cx_salv_msg.

ENDCLASS.                    “lcl_salv_model_list DEFINITION
*
CLASS lcl_salv_model_list IMPLEMENTATION.
  METHOD get_grid.
    DATA:
     lo_grid_adap TYPE REF TO cl_salv_grid_adapter,
     lo_fs_adap   TYPE REF TO cl_salv_fullscreen_adapter,
     lo_root      TYPE REF TO cx_root.

    TRY .
        lo_grid_adap ?= io_salv_model->r_controller->r_adapter.
      CATCH cx_root INTO lo_root.
        “could be fullscreen adaptper
        TRY .
            lo_fs_adap ?= io_salv_model->r_controller->r_adapter.
          CATCH cx_root INTO lo_root.
            RAISE EXCEPTION TYPE cx_salv_msg
              EXPORTING
                previous = lo_root
                msgid    = ’00’
                msgno    = ‘001’
                msgty    = ‘E’
                msgv1    = ‘Check PREVIOUS exception’.
        ENDTRY.
    ENDTRY.

    IF lo_grid_adap IS NOT INITIAL.
      ro_gui_alv_grid = lo_grid_adap->get_grid( ).
    ELSEIF lo_fs_adap IS NOT INITIAL.
      ro_gui_alv_grid = lo_fs_adap->get_grid( ).
    ELSE.
      RAISE EXCEPTION TYPE cx_salv_msg
        EXPORTING
          msgid = ’00’
          msgno = ‘001’
          msgty = ‘W’
          msgv1 = ‘Adapter is not bound yet’.
    ENDIF.

  ENDMETHOD.                    “get_grid

  METHOD get_tree.

    DATA:
     lo_tree_adap TYPE REF TO cl_salv_tree_adapter,
     lo_root      TYPE REF TO cx_root.

    TRY .
        lo_tree_adap ?= io_salv_model->r_controller->r_adapter.
      CATCH cx_root INTO lo_root.
        RAISE EXCEPTION TYPE cx_salv_msg
          EXPORTING
            previous = lo_root
            msgid    = ’00’
            msgno    = ‘001’
            msgty    = ‘E’
            msgv1    = ‘Check PREVIOUS exception’.
    ENDTRY.

    IF lo_tree_adap IS NOT BOUND.
      RAISE EXCEPTION TYPE cx_salv_msg
        EXPORTING
          msgid = ’00’
          msgno = ‘001’
          msgty = ‘W’
          msgv1 = ‘Adapter is not bound yet’.
    ENDIF.
    ro_tree = lo_tree_adap->r_tree.

  ENDMETHOD.                    “get_tree
ENDCLASS.                    “lcl_salv_model_list IMPLEMENTATION

To get the CL_GUI_ALV_TREE:

  DATA: lo_tree TYPE REF TO cl_gui_alv_tree.
  TRY .
      lo_tree = zcl_test_np_salv_model=>get_tree( gr_tree ).
    CATCH cx_salv_msg.

  ENDTRY.

Updated version of the ON_USER_COMMAND method in the original solution Power of ABAP Objects: Overcome the Restrictions of SALV Model

  METHOD on_user_command.
    DATA: lo_grid TYPE REF TO cl_gui_alv_grid.
    DATA: ls_layout TYPE lvc_s_layo.
    CASE e_salv_function.
*     Make ALV as Editable ALV
      WHEN ‘MYFUNCTION’.
*>>       
        TRY .
            lo_grid = zcl_test_np_salv_model=>get_grid( lo_report->o_salv ).
          CATCH cx_salv_msg.
        ENDTRY.
*<<       
        IF lo_grid IS BOUND.
*         Editable ALV
          ls_layoutedit = ‘X’.
*         Set the front layout of ALV
          CALL METHOD lo_grid->set_frontend_layout
            EXPORTING
              is_layout = ls_layout.
*         refresh the table
          CALL METHOD lo_grid->refresh_table_display.
        ENDIF.
    ENDCASE.
  ENDMETHOD.                    “on_user_command

Questions are …

These also raises to these questions:

  • Is SAP not planning to have SET_EDITABLE method in OM as they have started using this approach?
  • Would SAP now provide support if customer uses the same approach and run into issues?
  • If no, than how come SAP approved this design to exist it in customer’s system?
  • If yes, As you can see, the application was created in somewhere 2011 by SAP. So, the developer must be aware of the existence of my solution. Shouldn’t I get at least a some credit? Not that I want, but would be good to have, 😉

Please share your thoughts…

updated on 23-Jun-15 at 8:30 AM CST to add the missing local class

Assigned Tags

      31 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Custodio de Oliveira
      Custodio de Oliveira

      Excellent finding, Naimesh!

      Yes, they should give you credit. and yes, they should support this solution (actually they should make SALV editable already 🙁 )

      Cheers,

      Custodio

      Author's profile photo Former Member
      Former Member

      Well,

      Don't be too optimistic.

      I guess that this is just a case of one independent SAP Developer who read your blog 😉

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Great stuff. I didn't see your original blog at the time, but I've read it now, and I disagree with the nay-sayers. The fact is that if you're using this or your other solution (not workaround!), I find it very hard to see how you could break anything standard. And since SAP don't support anything custom you write anyway - what's the problem?

      In the real world, we're using and reusing SAP classes all over the place. If they were never designed to work in the way that we're using them... then perhaps that's design issue - not customer misbehaviour! If you don't intend us to use your classes in a particular way, then you should have written them so we couldn't.

      Decently written classes are extendable safely (pathalogical use notwithstanding). I can imagine the Java or C++ communities' response to a complaint that you're not using their libraries the way you want them to!

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      Agree that they shouldn't allow us - customers or even the internal SAP developers - if the class library is not supposed to be used by "others". Certainly that's not the case with this library. 

      SAP doesn't support the custom development but they have to at least entertain the customers query when customer is using the so called "released" function modules / classes. For few giant customers, they have to respond to the customer message even customer uses "unreleased" approach. I guess, they want to avoid the load of tickets created by this type of solutions by giving early (false) warnings - "this is not intended use", "we will not support", etc.

      Glad you get a chance to read through the original blog.

      Regards,
      Naimesh Patel

      Author's profile photo Flavio Furlan
      Flavio Furlan

      In the real world, we're using and reusing SAP classes all over the place. If they were never designed to work in the way that we're using them... then perhaps that's design issue - not customer misbehaviour! If you don't intend us to use your classes in a particular way, then you should have written them so we couldn't.

      It's true for editable SALV case, but could be dangerous if some reckless programmer use same argument to justify a direct update in a standard table.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Two points:

      1. good oo-design should minimise the chance of class misuse (which is the main thrust of my argument and not applicable to directly updating database tables).

      2. if you choose to use classes for purposes not designed, unreleased function modules or update tables directly, SAP do not have to support you. (This is counter to the argument presented by the SAP dev team, who said that people will come running to them when it doesn't work). Unless you're updating SAP tables (using SAP classes, FM or directly), you're unlikely to screw anything up that you can't fix yourself.

      Author's profile photo Paul Hardy
      Paul Hardy

      It occurs to me that SAP programmers are "real" people also. They experiment with things, they read the blogs on the SCN and no doubt use some of the things they read there as indeed I do.

      Some SAP developers are also are clearly interns out on their first day with no training provided and no testing of the code they write before it goes into production, clearly the ones who wrote the original release of SAP GUI 740 fall into that category, as did the developers who did the OSS note to enable account assignment on GR for purchase orders with multiple account assignment. That OSS note code mixed up BUKRS and WERKS and put the value for one into the other, and oh dear, the end result was not too good. It would have worked in an IDES system as both BUKRS and WERKS would have both had the value 1000, but not in any "customer" system.

      When the code exchange was hosted on SCN SAP reserved the right to use anything put there in the standard product and indeed did so with some JSON handling classes, which surprised (and probably flattered) the original author. He was happy as the SAP developer just copied the classes wholesale using SAPLINK and did not realise the author had a dummy method in one class with just a sort of copyright message in comments saying he had written the class in the first place.

      Anyway, the point is that SAP developers are no doubt just as frustrated as us "customer" programmers that the SALV is not editable and seek to work around this in the same way all the companies running SAP do.

      Thus I extend the comment I made recently:-

      "If a rule made by SAP is broken by all the companies using SAP, and internally by SAP developers i.e. the rule is broken by 100% of people, maybe it is time to look at the logic behind the rule?".

      But it won't happen. On the 9th anniversary I will be posting another blog commerating the fact of the non-event.

      In the interim I will be beefing up my work-around to try and use the techniques you use above.

      The question I would have is this - have you found a way to open a SALV screen in editable mode? Thus far I have always had to open it in read only mode, and then have a button for the user to press to make it editable.

      If I could solve that problem I would never need to use CL_GUI_ALV_GRID directly again.

      Cheersy Cheers

      Paul

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      SAP developers would even ask some silly questions. I would be surprised to see the question content and the SAP logo next to the name. So, either as you suggested they are interns and don’t have any on the job training, or SAP doesn’t have any Quality Assurance.

      Earlier I thought SAP has rigorous check-up, performance tuning, code cleanup, before they ship the code to customers. But now I know that they don’t even follow the standards which we follow at customers. In one DSD solution, there are many SELECT * FROM BSAD, BSID and being executed recurring time. The funny thing, is they don’t even need all 250+ fields as they only are interested in checking if there is any open item or any payment already posted for this customer. Certainly this type of code would have been only tested in IDES and SAP would have decided to include that in the next support pack / upgrade. Customer would have thought the new support pack is great (as SAP advertise) and boy oh boy, they would end up miserably using that. So, ultimately would end up ditching that or enhancing to the certain extend that there wont be a standard call anymore.

      The developer of that JSON handling class would be happy as his creation is now part of standard. But he might not had been criticize to create that solution as I had been for this .. Anyways, I think only the out-of-box solution would put an end to this.

      Regarding making SALV directly editable, I have few ideas. Let me run them through and would let you know how it goes.

      Regards,
      Naimesh Patel

      Author's profile photo Matthew Billingham
      Matthew Billingham

      I thought the QA department was named "Ramp-up customers" or "Early adopters". 😉 And while to be absolutely fair, much of SAP own code is very well written and designed (especially when you take into account the historical imperatives), there are some really doozies. I remember interviewing a chap and asking how he would improve his own coding. "By looking at SAP standard", he replied. "Oh dear" I thought... 😈

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      Hi Naimesh,

      At what point should someone choose to use a "Implicit enhancement"?


      If OK to implement, all you need is to have a few lines of code inserted at the end of CL_SALV_CONTROLLER_METADATA=>GET_SLIS_LAYOUT method, to say  S_LAYOUT-EDIT = 'X', correct? That will make the SALV editable directly, without having to go through all this trouble.


      Thanks,

      Juwin

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      I think its more than just changing the S_LAYOUT-EDIT = 'X' to make it editable in the method GET_SLIS_LAYOUT. Alongwith this, you would need to make sure toolbar appears with all the required buttons. Also, all required events are registered to handle the changes.

      You would need to replicate the similar enhancements for the Grid as the SLIS* methods would only get executed for the Fullscreen ALV. For GRID, the methods would be LVC*

      Gaining access to the underlying object (GRID or TREE) allows you to do many other things, like add a wallpaper to the header, register extra events (NODE_CONTEXT_MENU_REQUEST and ITEM_CONTEXT_MENU_REQUEST) for tree.

      I would refrain from using the implicit enhancements within the "helper" methods of the SALV OM models, as the architecture may change and enhancement wont be executed anymore. That would be also apply to this approach of gaining access -- but I guess it would at least raise syntax error, if that happens.

      Regards,
      Naimesh Patel

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      I think its more than just changing the S_LAYOUT-EDIT = 'X' to make it editable in the method GET_SLIS_LAYOUT. Alongwith this, you would need to make sure toolbar appears with all the required buttons. Also, all required events are registered to handle the changes.

      Hi Naimesh,

      I just changed the value of this field to X in debug mode and it gives me what I want - ALV in edit mode, with SAVE, and BACK buttons enabled. Whenever I make changes, press SAVE and clicks BACK, whatever changes I did on the screen, where passed back to the program.

      Toolbar can be activated by calling CL_SALV_TABLE->GET_FUNCTIONS( )->SET_ALL( ABAP_TRUE ), correct?

      So, which event am I missing?

      I understand that access to underlying object gives much more capabilities.

      Thanks,

      Juwin

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      Dont have normal "Edit" buttons when using the S_LAYOUT-EDIT = 'X'.

      std_SAP_SALV_FS_edit_buttons.png

      But, have all of them using my approach:

      std_SAP_SALV_FS_edit_buttons_all.png

      How are you handing event DATA_CHANGED to validate the entries by changing the only S_LAYOUT?

      Regards,
      Naimesh Patel

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      Hi Naimesh,

      You are right, I don't get DATA_CHANGED event, and the buttons.

      Thanks,

      Juwin

      Author's profile photo Jānis B
      Jānis B

      Juwin Pallipat Thomas wrote:

      Toolbar can be activated by calling CL_SALV_TABLE->GET_FUNCTIONS( )->SET_ALL( ABAP_TRUE ), correct?

      I didn't try, but I don't believe so, No, see previos comment. since  CL_SALV_FUNCTIONS_LIST encapsulates only a subset of ALV functions and the editing functions are to the very least not among those which can be controlled using the named methods of this class. Unless CL_SALV_FUNCTIONS_LIST->ADD_FUNCTION( ) + SET_FUNCTION( ) lets to set up and control editing functions as custom ones, they will have to be activated via some "funky stuff", I feel...

      cheers

      Janis

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      Hi Janis,

      Although SAP disabled the buttons/ didn't provide the buttons related to edit, the functionality for "Edit" is still present in the classes.

      In Edit mode,

      Right click on any row, and you get Cut/ Delete option.

      Ctrl+C, Ctrl+V etc also works.

      Pasting new rows also works.

      So, I don't think the functionalities were removed in CL_SALV_TABLE, they were just hidden.

      Thanks,

      Juwin

      Author's profile photo Jānis B
      Jānis B

      Right, and not hidden very well 🙂 SALV does add a whole new layer of, if I understand correctly, "MVC and convenience logic" on top; the potential challenge I don't like in going behind SALV directly to grid is: how to keep grid state "compatible" with that of SALV.

      cheers

      Janis

      Author's profile photo Jānis B
      Jānis B

      Err, yes - real people 🙂 I still feel that on average the level of SAP's ABAP developers, standards and procedures are above those of the custom developments I have seen...

      And the resistance to changes has more to do with real peoples real fears to screw up things in too many to count systems, I feel. Part of the response I got to my "guys, let's replace this call with another" bug fix proposal for simple sounding "BDT: required field check doesn't process all (field) status changes" problem illustratates:

      We cannot test all the scenarios. Sorry for the negative response as

      we cannot provide the standard SAP note for this.

      I have no idea about the technical challenges involved in getting to "editable SALV", but what I suspect is: maybe it's not so much unwillingness to do the "right thing", which many customers want - it's the inability to deliver a quality solution. The fear, which of course in turn reflects negatively on the quality of code base, developers, standards and procedures...

      cheers

      Janis

      Author's profile photo Paul Hardy
      Paul Hardy

      Naimesh,

      Have you yet found a way to get the SALV to open directly in edit mode?

      Thus far I have only been able to bring up the grid display for a SALV in read only mode, and have some sort of button so the user can change it into editable mode.

      With a real CL_GUI_ALV_GRID report you can display the report directly in editable mode without the user having to do anything, just like in SM30.

      And users do want this sort of thing.....

      I was sort of thinking this was impossible with a SAV as you cannot get your hands on the underlying object until after the report has been displayed.

      What do you think?

      Cheersy Cheers

      Paul

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      Hello Paul, I found a way to achieve it.. Almost finalizing the approach and testing it to make sure it works. Would send it out soon..

      Thanks for keeping me on my toes 😆

      Regards..

      Author's profile photo Jānis B
      Jānis B

      The "fullscreen" and "ALV grid in a container" adapters (I assume) seem to handle setting up the toolbars differently - "grid in a container" does not show the editing functions automatically.

      I can show CL_SALV_TABLE instance in a container in editmode as simply as calling its display( ), followed by getting and doing the "funky stuff" to grid (get_frontend_layout( ) + set_frontend_layout( )), followed by CL_SALV_TABLE->refresh( ) in PBO. Obviously, ALV at this point is without appropriate toolbar and most likely the events to handle the functionality, but those can likely be set up by doing more "funky stuff".

      There may also be a cleverer way without calling standard display( ), by instantiating and setting up the adapter and the grid in the "funky stuff" part... I feel, however, that doing the "funky stuff" to switch on editiable grid alone is already depending on SALV "implementation details" too much... I wish CL_SALV_TABLE was at least programmed to an interface, so it could be kind of "decorated" easier, if SAP didn't want us to inherit this class.

      Don't feel good about this solution; SAP should just do the "right thing"...

      Another small comment about the old solution: unlike fullscreen, for the grid in container SET_SCREEN_STATUS( ) is not supported for obvious reasons (check is programmed in CL_SALV_MODEL_BASE->SET_SCREEN_STATUS( )).

      Test code fragment:

            data: lo_grid TYPE ref to cl_gui_alv_grid .

            data: ls_layout TYPE LVC_S_LAYO .

            data: lt_fieldcat TYPE LVC_T_FCAT.

            FIELD-SYMBOLS: <ls_field> type LVC_S_FCAT .

            lo_functions = me->mo_alv_result_table->get_functions( ).

            lo_functions->set_all( IF_SALV_C_BOOL_SAP=>TRUE ).

            me->mo_alv_result_table->display( ).

            lo_grid = lcl_salv_model_list=>get_grid( me->mo_alv_result_table ) .

            lo_grid->set_ready_for_input( 1 ).

            lo_grid->get_frontend_fieldcatalog(

              IMPORTING

                et_fieldcatalog = lt_fieldcat

            ).

            loop at lt_fieldcat ASSIGNING <ls_field>

              where

                  FIELDNAME = 'RATETYPETEXT' .

                <ls_field>-edit = 'X' .

            endloop .

            lo_grid->set_frontend_fieldcatalog( lt_fieldcat  ).

            me->mo_alv_result_table->refresh( ).

      Result:Edit SALV.png

      Author's profile photo Juwin Pallipat Thomas
      Juwin Pallipat Thomas

      for the grid in container SET_SCREEN_STATUS( ) is not supported for obvious reasons (check is programmed in CL_SALV_MODEL_BASE->SET_SCREEN_STATUS( )).

      I liked it when SAP took a very useful class CL_GUI_ALV_GRID and encapsulated it to simplify the interface using CL_SALV_TABLE. But, I haven't quite understood why they disabled some of the basic functionalities of CL_GUI_ALV_GRID, like the events, status, edit etc.

      So, would you be able to tell, what are those obvious reasons?

      Thanks,

      Juwin

      Author's profile photo Jānis B
      Jānis B

      Hi,

      For one, "phylosophically" there is no real need to try to mess with "GUI status" of the whole application from within and via a "subcomponent" placed in a GUI container - application can control GUI status directly. In addition one can also imagine an application with several grid containers on one screen; then it gets a bit dicey, I feel.

      Fullscreen mode with one grid does away with those concerns (the grid IS the whole of application so to speak), but honestly - I don't yet understand the need to control application GUI status via CL_SALV_TABLE... To accomplish what - adding a GUI function and making grid aware of it with single method call..?

      cheers

      Janis

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      Hello Jānis,

      Correct that the Grid and Fullscreen has different trigger time. For the Grid, you are in PBO of the your own screen so the DISPLAY method doesn't actually bring up the ALV, the end of PBO does. For Fullscreen, ALV handles that so after DISPLAY, you don't have control anymore.

      Also the toolbar is tricky. the SALV grid has special functionality for the toolbar and it hides many of those. so, had to put those buttons back.

      I just published blog to cover this and make it happen using AFTER_REFRESH event. SALV Editable with Single (custom) Method

      Regards,
      Naimesh Patel

      Author's profile photo Naimesh Patel
      Naimesh Patel
      Blog Post Author

      Hello Paul,

      Just to close the loop - SALV Editable with Single (custom) Method the solution without the button ..

      Regards,
      Naimesh Patel

      Author's profile photo Former Member
      Former Member

      Excellent Naimesh ! I totally agree with your solution and i remember discussing about this topic in 2008.

      Author's profile photo Charulata Borkar
      Charulata Borkar

      this example is way easier:

       

      its just you have to use the adapter attribute of the model class than using r_Controller which is a protected attribute,

      http://harelgilor.blogspot.com/2010/11/abap-objects-alv-grid-manipulations.html

       

      Author's profile photo Srinivas Patchipulusu
      Srinivas Patchipulusu

      Very nice blog.

       

      Please provide full length . All your efforts will be utilized many of us like me.

      I am unable to use this code in the program.

      If possible can u share the full code . Showing errors get_grid and few . Thank you.

       

      Sreenu.tikku@gmail.com is my mail id

      Author's profile photo Markus Krätzschmar
      Markus Krätzschmar

      Hello.

      I found that post very helpful. The Button is what I needed.

      I was also able to set only specific columns editable by changing the frontend_fieldcatalog of the grid object.

      But I'm not able to restrict it to specific lines based on some values like shown in BCALV_EDIT_02. It seems that the grid object behind the SALV table ignores the Style tab in the data table (a column with type LVC_T_STYL).

      Was anyone able to extend the SALV editable functionality for just specific cells?

      Many thanks and regards

      Markus

      Author's profile photo huaxiang fan
      huaxiang fan

      Hi Naimesh,

      This is very great!

      Would you like to have a look at my issue as below please?

      When I used this approach to set salv grid editable, it works fine by setting { layout-edit = 'X' } or { fieldcat-edit = 'X' }.

      However, it can not work as editable ( input ready ) when I am coding as { l_layout-stylefname = 'l_layout-stylefname ' and other setting like standard program LFOT_RFD_MONIFE0 }

      This cell-level editing is used for primary key fields, so could you help me please?

      Thanks a lot.

      Michael

      Author's profile photo Clemens Li
      Clemens Li

      Hi Naimesh,

       

      great work and things change. As I noticed today, all get_grid( ) calls on program FOT_RFD_MONI have been comments meanwhile. It looks as if the locak class is not needef any longer. Please have a look and please explain...