The idea

I got the idea for this when I was working with the web dynpro view editor. I noticed there was something ALV like which was used instead of a classical dynpro to enter values on several fields:

I was wondering if I could use the ALV grid control for simple input areas in my own applications.

The implementation

I created a subclass to CL_GUI_ALV_GRID to achieve this. It uses a fixed output table structure containing a column for the label, one for the value (can be editable), and one for a field description (if we input on a field with domain values).

Attached to this blog you will find two files:

zp_ictrl_demo_screen.txt: contains the source of a demo report. You can upload it into a report on your system (ABAP 740 or later).

zp_ictrl_demo_screen_0001.txt: contains a download of the screen used to display the ALV control. You'll have to create the screen 0001 and then upload it from this file

To get the program running, create a GUI status 0001 with function code END on the SHIFT+F3 button. Create also a GUI title 0001 saying "Test program" or something similar.

Now, if you run the program, you should see something like this:

P_RDONLY starts the input in read only mode, otherwise the edit mode is active

P_SIMPLE: in read only mode, P_SIMPLE activates a simpler display with no key coloring.

Edit mode screen:

The demo class LCL_APP calls the input control with the structur ADDR1_VAL. As you see, you get a complete input for this structure using the call:

        create object go_input
           exporting
             iv_structure_name = 'ADDR1_DATA'
             io_parent         = go_container
             iv_max_outlen     = 30
             iv_readonly       = p_rdonly
             iv_simplex        = p_simple
             iv_max_outlen_d   = 30

In the demo program, I used the table parameter it_fieldattr to set the first two fields to read only.

Reusing the code

If you want to reuse the coding, you should extract the following classes from the provided source. Remember to do a find/replace for the class names transforming each "LCL_ICTRL" into "ZCL_ICTRL" and "LIF_ICTRL" into "ZCL_ICTRL" in the codings to get the classes working.

• lif_ictrl_input_check: This interface is useful if you want to code own input checks in your application. Implement it in your application class and pass the object reference to the main class. The interface method input_validate will be called for each input in the table. 
• lif_ictrl_types: This interface is needed for the necessary structure and table types.
• lcl_ictrl_alv : The main working class
• lcx_ictrl_fatal: Exception class used in the coding

Comments and hints

Since the coding "lives" in a standard super class, I decided to use a prefix ZICTRL_ for all objects I created in order to not interfer with further inserted attributes and methods in future releases of CL_GUI_ALV_GRID.

The work data structure is accessed by the caller via reference. You can set the reference using method ZICTRL_SET_DATA_BY_REF. In the demo application, a structure GS_DATA is kept as an instance attribute and the ICTRL_ALV class has the reference to it. As soon as GS_DATA is changed, just call ZICTRL_REFRESH to display the new data.

Use case example

I use this class frequently. It is very good in saving space in complex dialogue applications. Here is a screenshot of a productive GUI application:

If you try to put this information on a classical dynpro, you will occupy much more space on the screen.

Another advantage is that this control fits much better in an OO application than classical dynpros.

Disadvantages

Unfortunately there is one problem, which I did not resolve yet: Input fields in ALV grids do not have a frontend history. In some cases, when this is very important for the users, I had to refuse using it.

Conclusion

Feel free to post your comments. Bug annotations are always welcome!

All the best!

Jörg