International Editable SALV Day 2021 – Year 13
Dear CL_SALV_TABLE Fans,
Welcome to February 8th, 2021 which is the thirteenth (unlucky for end users) International Editable SALV Day. See below for a link to a blog I wrote to celebrate this day exactly one year ago
This day marks the 13th anniversary of James Hawthorne going cap in hand to SAP and suggesting maybe the CL_SALV_TABLE could be brought up to functional parity with the CL_GUI_ALV_GRID and have an option to be editable.
This series of blogs was feeling rather lonely, but another series of blogs has started this time about the ongoing refusal of SAP to decide about the BUILD product:
In addition, here is a link to a blog full of minor bugs in standard SAP that could be fixed in five seconds if there was a will/desire to do so
Going back to the SALV the situation is as follows
- CL_SALV_TABLE was introduced as the successor to CL_GUI_ALV_GRID many years ago and was supposed to be better in every way, more OO and so on.
- Sadly the “better” solution had less functionality than the solution it was supposed to replace e.g. in the areas of editability and adding custom functions in the toolbar
- This is ironic as the CL_SALV_TABLE is in fact a “wrapper” for the CL_GUI_ALV_GRID
Meanwhile back in the real world, the end users keep asking us poor developer types to make reports editable. The easiest way to do this is to migrate your program from CL_SALV_TABLE back to CL_GUI_ALV_GRID whilst keeping the one function CL_SALV_TABLE is good at i.e. generating a field catalogue from an internal table.
Many programmers, myself included, have written blogs and what not describing how to get around the editable limitation using assorted dirty tricks. The programmers at SAP did react to that, closing off the workarounds when they could.
In essence the question is – if SAP has a million end users and tens of thousands of “customer” developers and every single one of them wants something and it is easy to provide, why the outright refusal to provide it?
You might say I’m a dreamer, but I’m not the only one. Someday SAP might join us, and the world will be as one. This has in fact happened once in the past – SAP refused to enhance business workflow for over ten years, hoping people would pay a separate license fee for an equivalent product instead. In the end they caved in and added new features and updated the ABAP editor in SWO1 to the latest version and so on.
It could be argued that in nine years’ time everyone will have to move to S/4HANA and so the SAP GUI “problem” goes away, but if that is the case why is so much effort being invested in new features in the SAP GUI. The bug filled SAP GUI 7.70 came out the other day, and that has tons of new features, some of them even work.
The problem with that argument (soon no-one will use the SAP GUI and hence the ALV) is that many organizations that have made the jump to S/4HANA have chosen the on-premise version, so they will be using the SAP GUI possibly beyond 2030 as getting everyone to use UI5 is not as easy as some had hoped.
In any event, to sum up, the whole thing is futile. The SALV will remain as non-editable no matter that 100% of people wish the opposite. It is like when the UK government had a vote on what to call the new Antarctic explorer and the winner by a landslide was “Boaty McBoatface” but the UK government did not like the result of that democratic election and so called the ship “Sir David Attenborough” instead. There was another democratic election somewhere recently where the incumbent refused to accept the result, but I cannot recall exactly what country that was.
In an effort to support democracy Sir David Attenborough has announced he is going to change his name by deed poll to “Sir Boaty McBoatface” so the name of the ship will have to change as well, and in that country I shall not name the vote of the people won in the end, but when it comes to the SALV it is rather like Otis Redding sang in 1967, the year before I was born:
I’m writin’ these SALV blogs, wastin’ time
Look like nothin’s gonna change
Everything, still remains the same
SALV can’t do what ten million people want it to do
So I guess It’ll remain the same, yes
See you next year!
It's 2AM in Germany at the moment (on Feb 8th). When they wake up it will be February 8th. It will not be Feb 8 in Boston for another four hours I have to admit, and seven hours in California.
So yes I confuse "most of the world" if you exclude from the world China, India and Europe, all of which have incredibly small populations.
Here in California, in the county which will not be named, it is February 8th. I will celebrate International Editable SALV Day this year by releasing a new, editable ALV report using CL_GUI_ALV_GRID.
Thank you, as always, for the post.
I feel a little frisson of fame here, because I used to work with Jim 'Jimbo' Hawthorne. He was quite a character. He referred to HR as 'Human Remains' and was always tinkering with ALV. Nice to see that he has achieved some kind of immortality in this series of blogs.
You forgot to mention one important point:
Leave CL_SALV_TABLE for a moment,
even in the good old CL_GUI_ALV_GRID, The edit functionality isn't supported by SAP.
(Check note 695910 - "ALV Grid: Grid that can be edited and unreleased methods" for further info)
First off, going into the SAP support portal to read the note and then coming back here has taken over half an hour due to the lunatic authorization system i.e. need an "S" user for the support portal, need a "P" user for SCN, need internet explorer for the SAP support portal, need chrome for SCN and so on.
That was a very interesting note and I was unaware of it. it says, in essence, that the edit functionality in CL_GUI_ALV_GRID works but if you use it and run into trouble then you will get a bill for "one million dollars". Boo Ha Ha! Boo Ha Ha!
So the only official way to edit data in the SAP GUI is via a table control in a DYNPRO. I don't think I need to say anything else.
Thank you for keeping up this tradition for so long! You are setting a good example. Actually, I think many of our customers have learned not to expect much, which is a mistake.
The reason people sometimes get nostalgic about shit is that they remember how it looked back when it was still food. To help them reevaluate the current situation, it helps to express the appropriate amount of disgust. Especially if you're paying for it. Don't let the corporations win!
I have high hopes for this year though. The world keeps getting weirder, so one day it might even occur that SAP starts fixing their old software.
Or at least not fire their employees who rise up against their corporation's policies 😉
Honesty is one of our key policies. If anything, this should get me a raise.
I don't want to help SAP on this point, because they don't release a feature that they use for their own developments.
BUT, I have to agree that editing in ALV is not very intuitive, the cell is tiny, when you click you can select the all cell or edit the value... theses may be the reasons it is not supported by SAP, as Shai Sinai mentions (thank you because I knew there was a note, but couldn't find it anymore).
This is why I always try to convince the end user to do it another way.
1.You mention table control, i think that it is, indeed, a faster way to put data into a table. You lost some features that are not indispensable in edit mode like sorting, filtering (you can filter with selection screen). If you need excel export, you can still create a new program with SALV for display only, it's fast. If you want lights, colors, icons, or if it is really important to manage lots of lines, you can go for option 2.
2. You can stick with the SALV, but when you double click on a row (or edit button in a cell, or select the row and edit button in the toolbar), a dialog open with all the fields of the row that you can edit there.
Note that the second option behave the same as the Fiori List Report -> Object page. You cannot edit data directly in the list report, you have to navigate to the object page.
To be honest I prefer using table controls in a DYNPRO to edit data. The boxes are bigger, you don't have to manually clear out the initial value, you can always tell where you cursor is, and so on.
Just this day I have a ticket to look at whereby the width of an editable cell in CL_GUI_ALV_GRID is different for different users - some can only enter the first character, some all five.
But none of that is the point. The point is that end users keep asking for editable ALV grids, they like them even if I don't.
The other point is that if you release a new version of something and claim it is better than the old one then the new one should have at least all the popular features enabled by the old one. That is not a radical idea, surely?
I have read your ALV chapter in your book "ABAP to the Future 3" and your blog "SALV and PEPPER : Editing individual columns in the SALV".
To make it short: Great work but it's sometime as horrible as your monster example. I spend a lot of time to make your programs run and to change the monster data base to the flight model, because I did not found a data generator....
I'm still facing some issues and not sure, if you found a solution for some topics you tried to implement.
Maybe your creative way of making SALV_TABLE editable is "fixed" by SAP or it is not possible or I don't know how to do it......
But nevertheless, I want to thank you for the great ALV stuff, you have published!
I have come to the conclusion that it is impossible to make individual cells editable in CL_SALV_TABLE. I can pass the correct values in to the CELLTAB for a cell in a table row, but it just does not work, whereas it works perfectly in CL_GUI_ALV_GRID.
You can make the grid editable straight away if you so desire in CL_SALV_TABLE. I'll have to add that in to the next edition. Your idea for a data generator like SFLIGHT has is really good as well.
i use this in real life at my company and have never encountered the dump when the grid is over 100 lines.
Really though as things stand you are best off using CL_SALV_TABLE to generate the field catalogue and then using CL_GUI_ALV_GRID for everything else.
Is that still your current conclusion? I have individual cell editing working in 7.0 for a few years now, but we're upgrading to 7.5 and that part no longer works. Your conclusion doesn't give me much hope of solving this, which means a few of our screens will break. 🙄
I still have not found a way to do it. In regard to upgrades breaking CL_SALV_TABLE workarounds that is because some developers at SAP read blogs like mine which tell you how to make the grid editable and then change the standard SAP code so the workaround no longer works.
I have no idea but I imagine the amount of time and effort spent changing the code to suppress the workarounds is probably ten or twenty times the amount of effort it would take to make the CL_SALV_TABLE editable in standard.
It is like in the road where I lived. the council painted on the road something that looked like a zebra crossing so people started using it as a zebra crossing. So the council paid to put up a sign on either side explaining it was not actually a zebra crossing it just looked like one. that did not work so they PAID SOMEONE to stand there all day long and whenever anybody tried to cross explain to them it was not actually a zebra crossing. I would note at this point that cars treated it like a zebra crossing because it looked like one and always stopped when people were using it to cross the road.
You cannot make this sort of stuff up.
Eventually the council gave up and let it actually be a zebra crossing. Had the council been SAP they would have spent extra money removing the paint from the road.
If I knew what they changed, maybe I could fix it, but like you said, it doesn't respect my control field anymore. Full column edit still works. I would have used FALV from the start, if I had known it'd be like this.
As it is, I feel more like the zebra, thinking that SAP made the zebra crossing for me, but clearly it's a zebra crossing (or CL_GUI_ALV_GRID wrapper) in name only. This analogy only works like 60%.
Actually, I found the change now. Form routine DATA_TABLE_GET in LSLVCF05 checks if IR_SALV_ADAPTER is bound. If it is, it skips the part that sets the style that basically means editing. Instead, in the same routine, it uses the celltype stuff in the SALV, but celltype doesn't include editing.I think there's more to it though, because just editing in the style in the appropriate field is not enough.
Per the comments, the change has been made as part of "YI3K104189". I'm curious to read the contents of it.
I don't see this working again on an upgraded system. I'm very sad.
As Hardy yet pointed out, we are on S/4 Hana since last year and still use SAP GUI and (S)ALV. There has never been a serious, suitable successor of it.
Btw, did I mention we are running an on-premise installation? No cloud that SAP highly propagates and prays us to use? IMO, this won't be an option the next years either, at least here not in Germany.
Fiori and its table layouts is still not the way to go and cannot do inline editing either. Fiori looks nice, no doubt, however there are too many annoying IDEs that we are expected to use to writing Fiori apps, that are changing almost each year.
One year ADT is the way to go (according to SAP), the other year it's VSCode that gets pushed and next year it's Business Application Studio. And once upon a time there even was a WebIDE, you remember?
ADT is still a PITA for any serious development and Business Application Studio costs you a license, nevertheless we are on-premise. I use ADT for writing CDS-Views and have done it for just one single use case so far! All other development is still done using SAP-GUI.
At the moment I'm struggling with editing a class' text and their long textin ADT. Do not have any clue so far where to search. For editing text elements, ADT opens an inline SAP GUI! Come on SAP, we are in year 2021, you know and still get such cheaply programmed editors we are supposed to use for programming now and in future! You can't be serious!
Just saw your comment... luckily in 2022, SAP has heard you and provided the text elements editing within ADT itself
In fact I've started using ADT for over 80% of development work in SAP. Even opening the SAP GUI seems to be easier just from ADT, rather than logging into another GUI session.