How to render CL_GUI_ALV_GRID in background
Someone decided to run an editable ALV (based on CL_GUI_ALV_GRID) in background. It dumped. The solution is simple but not that obvious.
Someone decided to run an editable ALV (based on CL_GUI_ALV_GRID) in background. It dumped. The solution is simple but not that obvious.
Nowadays I rarely use CL_GUI_ALV_GRID because SALV is so much better. But when I am asked to make an editable ALV I still use it. Until very recently, I thought that, in order to use it, I needed a screen with a container. And because I’m using ABAP OO, I’d need a function group to host it and a function module to call it. Painful.
Sometimes the simplest things take the longest time to do. For instance, we recently needed an ALV grid to automatically resize to fill the whole window. But how? But how? But how?
I don’t know for how long has this been available but I just now found out about it. In the debugger it is, after all, super easy to see the content of an internal table in an ALV.
We’re all lazy. It’s just human. Programmers are human. We’re often lazy when it comes to the way we program something. And usually being lazy when making a program will result in someone else having more work when maintaining it.
Let he who is free of laziness throw the first rock.
I won’t!
When you want to use CL_GUI_ALV_GRID in a CONTAINER you must copy a standard Status GUI from another program. For example, the GUI Status “STANDARD” of the function group SALV. And then, in the screen’s PAI you do:
SET PF-STATUS ‘STANDARD’.
And thus the little standard buttons show up on your screen.
It is common to find an ALV data structure explicitly defined in the code. If this is done, the field catalog has to be manually constructed. If a predefined structure (from DDIC or declared as a TYPE) is used instead, the field catalog can be automatically built. This approach is always better and results in less code, even if the field catalog needs to be adjusted here and there. https://abapinho.com/en/2011/12/automatizar-catalogo-alv/
SALV classes are more versatile and more recent than the old function modules. So, for new ALVs always use SALV. The only exception is editable ALVs which SALV classes are still very incapable of doing. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366
Unless you want to do data editing, the only dignified way to use ALVs these days is through SALV classes. They are more modern and more elegant, and those who use them can achieve a social status until now only available to owners of a license plate.
Do you know how to present an ALV with a list of records in a dialogue box allowing multiple choice? I didn’t. But I do now. Let me explain how.
Sometimes I ask myself what percentage of the world’s ABAP code is unnecessary. A paradigmatic example of how time can be wasted writing code which is of no use to anyone and only creates problems is the ALV’s all-too-common field description definition sitting directly in ABAP.