My favourite cryptic ST22 dumps around CL_GUI_ALV_TREE
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.
Re: Dump 2 - yeah, there should be created "expand_all_nodes" method /or some nice getters for nodes (get_top_nodes or so...).
Until class update, we need use expand_nodes with own logic to find expandable nodes 🙁
Thank you for this post!
Saved hours of searching, you made my day (night).
I had the same issue with expand_node, not surprisingly the solution with get_first_child works here, too.
🙂
Hi!
Thanks for this information!
But also do not try to expand “hidden” nodes. This will also result in a Dump in class CL_GUI_CFW method FLUSH.
In my scenario a node has children when the layout-expander is set. Therefore i don't need to check if a child is there:
SPAN { font-family: "Courier New"; font-size: 10pt; color: #000000; background: #FFFFFF; } .L0S33 { color: #4DA619; } .L0S52 { color: #0000FF; } .L0S55 { color: #800080; } .L0S70 { color: #808080; } LOOP AT mt_nodetab ASSIGNING FIELD-SYMBOL(<node>).
CALL METHOD mo_bom_tree->get_outtab_line
EXPORTING
i_node_key = <node>
IMPORTING
es_node_layout = ls_node_layout.
IF ls_node_layout-expander = 'X' AND
ls_node_layout-hidden IS INITIAL.
CALL METHOD mo_bom_tree->expand_node
EXPORTING
i_node_key = <node>.
ENDIF.
ENDLOOP.
SAP to consider repairing? It is year 2018 and some features were not even put between „mortal“ programmers (read the ones outside of SAP)...
Sometimes I just wonders, why so many companies use this...
Man you made my day! Had DUMP #2 as well... was trying to expand the lowest leafs of the tree not their parents...
In retrospective it makes sense that these are not expandable but... i had expeted a more appropriate errorhandling here...
so thanks mate this blog post saved me some more hours of debugging *THUMPS UP*
Hi Otto,
I found this post because I had precisely the first of your described dumps:
RAISE_EXCEPTION in CL_ALV_TREE_BASE method QUEUE_APPEND_NODES
Unfortunately, the quick solution that worked in your case ("oh, you have this dump? Don't think further, just add a tree->frontend_update( ) at an appropriate place!") didn't work here.
So I quickly removed the call - as future developers who come to this statements wouldn't dare to remove it later, and leaving such statements in the code, would "enrich" the program with useless stuff considered as a somehow magic requisite for its correct function. (cf. the advice "Avoid fortune-telling" of the pragmatic programmers).
And looked for the root cause.
I wanted to perform a drag&drop operation, with the aim of moving a node with its complete subtree into another part of the tree. Sometimes this worked, sometimes, I got the dump.
Playing around in order to find out when precisely it worked and when not, I saw that it always worked if the target node was already expanded at least at the first level. Whenever this was not the case, I got the RAISE_EXCEPTION. Something went wrong, because the internal table MT_C_P_MANAGER of the CL_ALV_TREE_BASE class had incorrect information about the child nodes of the target node in this case.
So the solution was simply to add a call of method EXPAND_NODE in my drop event handler, before actually performing the call of method MOVE_NODE.
I would have expected that the CL_GUI_ALV_TREE would perform this EXPAND_NODE internally to avoid this problem, but who am I.
Regards,
Rüdiger