My favourite cryptic ST22 dumps around CL_GUI_ALV_TREE

[OttoGold]

Before you read this: I’ve spent some time debugging the things I describe here, I thoroughly searched SCN, I used my brain and although it can sound like one big low-brainer what I describe here, I still think it is worth writing about it. I don’t think I am a beginner with ALV, be it grid ALV or tree ALV and this was driving me nuts for two hours. And it is un-debug-able.

In case the lesson learnt is not clear after reading the blog I rather put it right here upfront. Most (if not all) cryptic ALV dumps are caused by your program errors rather than SAP GUI problems, patch levels etc. The ALV classes are not so “smart” (or “tolerant”) as I would build them.

Dump 1: class CL_ALV_TREE_BASE method QUEUE_APPEND_NODES

Symptom: My code building a CL_GUI_ALV_TREE finished without any errors. I was catching and handling all SY-SUBRC problems returned by the CL_GUI_ALV_TREE methods so the problem could not be coming from there. I mean it couldn’t be a missing exception not handled correctly. Also no SY-SUBRC problem ever happened in the coding. The UI was drawing the ALV tree correctly too.

The problem was only hitting the program when I wanted to expand one of the nodes. No nodes were created expanded, but the nodes that were direct children of the VIRTUAL_ROOT were visible of course (in other words my tree does not have one root node only, it has a list of “root” nodes). When I clicked on the expander of these nodes, I got the dump below.

Analysis: I checked SDN. Three posts (I probably took the wrong keywords… I tried multiple combinations though). Two were duplicates (one thread about the same problem without any answer and one hijacked post by the person who posted the first one) and the third one was irrelevant. Some less relevant posts were suggesting that it is “definitely” a patch level or a SAP GUI problem. But I also saw some wise men and women saying that it can be a coding problem.

Solution: Eureka moment stroke and I tried to add CALL METHOD me->tree->frontend_update. That fixed the problem. So at the end of my PBO method the front-end update was needed. Without it the UI got created but dumped afterwards. Maybe this is a low-brainer. But maybe this spares other people some time when the search (it should also spare the SCN some questions about it too).

Keywords if anyone searches about the problem in the future:

"RAISE_EXCEPTION" " "

"CL_ALV_TREE_BASE==============CP" or "CL_ALV_TREE_BASE==============CM014"

"QUEUE_APPEND_NODES"

Dump 2: class CL_GUI_CFW method FLUSH

Symptom: No problems happen when the tree ALV hierarchy is being built but when it comes to flushing the UI so the user can have some fun too, you hit this dump.

Analysis: I was experimenting a bit, so I knew what could be causing the problem. Lesson learnt: Don’t try to be too smart. What I wanted to achieve was I wanted to expand all nodes in my tree with one simple command (without collecting the first level nodes, which are “roots” -> this is crazy for someone who knows that a tree has one root only, otherwise it is a forest, isn’t it). So what I tried was the following:

me->tree->expand_node( i_node_key = me->tree->c_virtual_root_node i_expand_subtree = 'X' ).

Unfortunately SAP was not "nice" enough to support such an option. That also explains the number of SCN posts asking about how to expand the whole tree at once and no post I found proposed a simple solution for this. Some suggested creating an explicit “artificial” root so that you have a root that you can expand that one with one simple command (EXPAND_NODE with the correct I_NODE_KEY), others suggested collecting the nodes you want to expand into a list and calling EXPAND_NODES instead. Take your pick.

If I may have a wish, could someone in the ALV development team at SAP consider supporting this? I mean the C_VIRTUAL_ROOT_NODE constant as a special case? If not, I would be interested to know why not (what is preventing it, why it is a good idea or why it is not needed -> so that I don’t have to create a mess in my program by collecting nodes I need to expand).

Bad idea number 2: I want to expand my whole ALV tree using the following:

  CLEAR lt_keys[].
LOOP AT me->mapping ASSIGNING <fs_map>.
APPEND <fs_map>-nkey TO lt_keys.
ENDLOOP.

CALL METHOD me->tree->frontend_update.

me->tree->expand_nodes( it_node_key = lt_keys ).

CALL METHOD me->tree->frontend_update.

BOOM! The same dump again. So maybe we have too many front-end updates here. So we remove the first one and… BOOM! The previous dump (QUEUE_APPEND_NODES) comes again. So the following does not work either.

me->tree->expand_nodes( it_node_key = lt_keys ).

CALL METHOD me->tree->frontend_update.

Maybe we could swtch the two commands like this…?

  CALL METHOD me->tree->frontend_update.

me->tree->expand_nodes( it_node_key = lt_keys ).

BOOM! The FLUSH dump again.

Last idea around the topic: Maybe the problem is that EXPAND_NODES calls front-end update too? Then EXPAND_NODES only (without any front-end updates) could work? Nope. QUEUE_APPEND_NODES dump strikes again.

Completely different idea: Maybe the tree control is not so smart and when I add a node I want expanded which has no children (no point in expanding), then it dumps. So I check that in my coding and let’s see what happens. The code now looks like this:

  CLEAR lt_keys[].
LOOP AT me->mapping ASSIGNING <fs_map>.
CALL METHOD me->tree->get_first_child
EXPORTING
i_node_key       = <fs_map>-nkey
IMPORTING
e_child_node_key = lv_dummy.
IF NOT lv_dummy IS INITIAL.
APPEND <fs_map>-nkey TO lt_keys.
ENDIF.
ENDLOOP.

CALL METHOD me->tree->frontend_update.

me->tree->expand_nodes( it_node_key = lt_keys ).

…and drumrolls… it works now

Keywords if anyone searches about the problem in the future:

"MESSAGE_TYPE_X" " "

"CL_GUI_CFW====================CP" or "CL_GUI_CFW====================CM002"

"FLUSH"

CALL FUNCTION 'AC_FLUSH_CALL'

     EXPORTING

SYSTEM_FLUSH = ' '

     IMPORTING

MESSAGE_NR   = rc

MESSAGE_TEXT = msgli.

    WHEN 2.

* method_call_error

      MESSAGE ID 'CNDP' TYPE 'X' NUMBER 006 RAISING CNTL_ERROR.

Dump 3: Surprise! Surprise! No more dumps…

Last but not least: Some fun with dumps (sounds like "Fun with flags", right?). This is a real one, not a joke.