SAPGUI is dying but still secrets to reveal…

In a recent twitter “conversation” I asked for common programming mistakes. One answer I got was:

Any use of ABAP presentation layer, ALV etc. in custom development. Deprecated technology that will make migration to public cloud harder.

Ok… SAP-Skript is also dying for years… 😉

I think that SAPGUI and GUI-Controls will rule the daily work of many SAP developers for many years.

Anyway. The reason of this blog post is another common mistakes that do appear again and again. If if you are an experienced pogrammer:

Multiple control instances

When creation a GUI-Control you need to have a parent container. One common mistake is, that the control will be created again and again. That’s possible but the user will only see the control that was created at first.

If you know, what you do, you can stack multiple different controls in a container and make sure that only one is visible.

Here is a little (german) demo: https://www.tricktresor.de/blog/controls-stapeln/

The only way to identify this error is to have a look at the children table of the CL_GUI_CONTAINER reference.

Container structure

I had the idea of visualizing the container structure:

Identifying object references

Displaying the structure is easy if the top container is given, because all children are stored in the attribute table CHILDREN of each control.

The diffcult part is: How to identify these objects so that you know which object referrs to what variable in your program.

There are two possibilities:

1. Find out the internal object id that is used in the debugger to identify the object instances.
2. Find out the name of the variable

Solution 1 – getting the object id

The internal object id can be found out with a system call:

    CALL 'OBJMGR_GET_INFO' ID 'OPNAME' FIELD 'GET_OBJID'
                           ID 'OBJID'  FIELD lv_object_id
                           ID 'OBJ'    FIELD io_object.

The type of the object can be found out by using the RTTI (run time type information):

DATA lo_obj TYPE REF TO cl_abap_objectdescr.
lo_obj ?= cl_abap_typedescr=>describe_by_object_ref( io_object ).
DATA(lv_relname) = lo_obj->get_relative_name( ).
DATA(lv_absname) = lo_obj->absolute_name.

With this information I can create the object identification like seen in the debugger:

rv_object_name = |\{O:{ lv_object_id }*{ lo_obj->absolute_name }|.

This information also makes building the tree very comfortable because I have unique object names.

Solution 2 – finding the variable name

Finding out the name of a variable to a specific object is easy if it globally defined in a program. Here you can use function module GET_GLOBAL_SYMBOLS to get a list of all used variables.

There are some helpful fields in the result table of this function module. Object instances are of type “r” and reftypeloc “CLAS”.

Using a dirty-assign I can get the objects reference and store it in an internal table to display variable name to the object id.

FIELD-SYMBOLS <object> TYPE any.
DATA lv_global_name TYPE string.
lv_global_name = |({ iv_repid }){ ls_fieldinfo-name }|.
ASSIGN (lv_global_name) TO <object>.

Displaying the container structure

With all these information I can display the container structure of a given object. For containers placed on dynpro I can display the children of CL_GUI_CONTAINER=>SCREEN0 or SCREEN1 (Depending on the popup level).

Containers that are not directly linked to a dynpro, like CL_GUI_DOCKING_CONTAINER or CL_GUI_DIALOGBOX_CONTAINER can only be displayed by providing the instance.

Object information

For another project I experienced with the neglected attribute “name” of each object. There are some strange behaviours when using this attribute:

1. If you provide the NAME parameter on instantiation of an object, it will have no effect. You will have to explicitely define the name witch method SET_NAME
2. If you apply this method to a control you will get the exception PARENT_NO_NAME which absolutely makes no sense to me. Why does a container must have a name when setting the name of the control?

Nevertheless, adding the name to a control can make it easier to identify controls and container. If the container is a CL_GUI_CUSTOM_CONTAINER then the name of the Dynpro area will be set what is very helpful.

Usage

To use this tool you need to implement one single line at the end of the PAI of a dynpro:

zcl_trcktrsr_container_tree=>factory( sy-repid )->show( io_control = go_parent ).

The dialogbox will show you the structure of the container hierarchy.

Another alternative is to place the code line in the Debugger script window at METHOD script. Choose Execute directly at the left side and press Execute script.

Optimization

There are some enhancements I could think of…

Refresh functionality

There should be a button or special node entry for refreshing the current structure.

Adding different controls

Up to now you are able to add one control to be displayed. Especially if you have many docking container it would be helpful to add all these container to the display.

Bottom to top

In this version you need to set the top container to see the structure below. It would also be helpful if you provied any control and the structure to the top will also be analysed and displayed.

Tool in debugger

I also can imagine that it should be possible to add a tool to the standard debugger. The same way you can analyse a data structure you could insert the name or the id of a control and the structure will be displayed directly in the debugger. Double clicking on an object leads you to the detail view.

Medicals by Larsiohvam

Thanks to Lars Hvam the code can be seen and tested at Gihub https://github.com/tricktresor/container_hierarchy