Here is one for you. Although such a language construction does not make much sense I would like to know why the nested LOOP AT SCREEN cause infinite loop (recursion?).
Let us take the following simple program.
REPORT yyy.
PARAMETERS:
p_x1 TYPE abap_bool.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
BREAK-POINT.
ENDLOOP.
The BREAK-POINT statement will be executed only 4 times. This leads to an assumption that such a nested loop would run 16 times. Instead the below mentioned program runs forever and ends with a timeout exception.
REPORT yyy.
PARAMETERS:
p_x1 TYPE abap_bool.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
LOOP AT SCREEN.
ASSERT 1 = 1.
ENDLOOP.
ENDLOOP.
It looks like nesting LOOP AT SCREEN causes either an infinite loop or some kind of an infinite recursion.
Why is it so? Is it documented somewhere? The extended check does not report anything regarding the loop. The same applies to Code Inspector as well.
EDIT
I have also checked whether this is a general problem for internal tables with a header line. It seems not.
REPORT YYY.
DATA: gt_t000 TYPE t000 OCCURS 10 WITH HEADER LINE.
START-OF-SELECTION.
SELECT * FROM t000
INTO TABLE gt_t000[].
LOOP AT gt_t000.
LOOP AT gt_t000.
WRITE / gt_t000-mandt.
ENDLOOP.
ENDLOOP.
LOOP AT SCREENshould not be regarded as a loop at an internal table. These are 2 distinct docs. SAP could admit a bug; maybe they saw it but thought a correction was useless, a nested loop is non-sense. Ask SAP for a correction. PS: you can imagine what happens internally: it's not an internal table, so there's an element counter which is reset at ENDLOOP. - Sandra RossiLOOP AT SCREENsays: "The statement LOOP AT SCREEN behaves like the statement LOOP in a loop across an internal table, where a system table is used instead of an internal table." So sounds like a nested LOOP should work, and you found a bug. :-) - Florian