The principle for the statements LOOP
and ENDLOOP
on a screen, representing repeating groups of fields (typically lines).
Whenever a LOOP
is placed in the screen painter, the process logic has to be adapted as well. ABAP has a solution for repeating field groups in a DYNPRO. The statements LOOP
and ENDLOOP
indicate which fields are placed in the LOOP
LOOP
and ENDLOOP
must be placed in bothPROCESS BEFORE OUTPUT
and PROCESS AFTER INPUT
. The loop lines are processed one by one in the flow logic. The ABAP developer thus only has develop a field check module for a singleLOOP
line, which will be used for all lines.
Field values are checked in the Process After Input. It may occur that the end user has entered new lines. If an end user skips a line when entering new data in a LOOP
, you will not be able to trace this back in the ABAP. Empty LOOP
lines are removed from the list before the ABAP can touch them. No worries there !
Walking through LOOP
s
LOOP
fields can of course contain more data lines than the number of lines that fits the screen. A positioning mechanism can be worked out; a counter would indicate the position in the LOOP
.Here's some help: on the menu of a DYNPRO you can indicate what keys are used for PageUp, PageDown, Top and Bottom. Fill in these function codings with the R/3 standard: P++, P+, P- en P--. R/3 now knows that the function keys concern the LOOP
in the DYNPRO.
Example: A step LOOP implemented
This example shows a LOOP
list on the screen.
*----------------------------------------------------------------------- PROCESS BEFORE OUTPUT. *----------------------------------------------------------------------- LOOP. MODULE D1300_HANDLE_LOOP. ENDLOOP. *----------------------------------------------------------------------- PROCESS AFTER INPUT. *----------------------------------------------------------------------- LOOP. FIELD TABNAME-FIELD MODULE D1300_FIELD. FIELD ZTRM-TRMSRT MODULE D1300_TRMSRT. CHAIN. FIELD TABNAME-RBEDR. FIELD TABNAME-ABEDR MODULE D1300_RBEDR. ENDCHAIN. ENDLOOP. FIELD LIST_POSITION MODULE D1300_POSITION. "End user can enter position MODULE D1300_MENU_RESPONS. |
The module that gets the LOOP
data, and puts it on the screen, could look like this:
*----------------------------------------------------------------------- * MODULE: D1300_HANDLE_LOOP INPUT. *----------------------------------------------------------------------- * Filling in the LOOP data from ABAP memory *----------------------------------------------------------------------- MODULE D1300_HANDLE_LOOP INPUT. MOVE-CORRESPONDING SOURCETABLE TO TABNAME. ENDMODULE. |
Statement LOOP AT
When processing data from an internal table, the ABAP has some more possibilities: LOOP AT
has the following extensions:
LOOP AT internal_table FROM index1 TO index2 CURSOR index3.
The statements FROM .. TO ..
are optional. The index variables are declared with LIKE SY-TABIX
and have the following meaning: the internal table can be walked through starting at line index1 and ending at index2 (included). The variable index3 is very important: it indicates the position of the loop. When this value is for example 3, then the first line of the LOOP
table on the screen is the third line from the internal table in the ABAP. In addition, when using LOOP AT
with CURSOR
the screen is enriched with a vertical scroll bar that can be used for the screen table. When repositioning via e.g. toolbar buttons (page up and page down) is necessary, the variable index3 can be directly adjusted.
There is another reason why LOOP AT
is chosen for screens with internal tables. It is of course possible to put the data of a table in a DYNPRO by means of the LOOP
statement. The exchange between the internal table <=> DYNPRO will be done as follows: the internal table has for example 4 fields of which 3 actually form the DYNPRO. With Process Before Output the data is passed per table line; so the 4 fields are passed to the DYNPRO, something is actually done with 3 of these fields. In Process After Input the data is read back and placed in the internal table; the fourth field will be erased as the DYNPRO does not deal with it (and actually cleared it). Because this field has been emptied, a modify table cannot be done ruckzichtslos.
Example: The flow logic for a LOOP in a screen
An example, the flow logic of the screen:
*----------------------------------------------------------------------- PROCESS BEFORE OUTPUT. *----------------------------------------------------------------------- LOOP AT T CURSOR CURPOS. ENDLOOP. *----------------------------------------------------------------------- PROCESS AFTER INPUT. *----------------------------------------------------------------------- LOOP AT T. FIELD T-VELD MODULE LINE_IN ON REQUEST. ENDLOOP. |
And a little preperation in the ABAP source:
DATA: CURPOS LIKE SY-TABIX. BEGIN OF T OCCURS 100, FIELD, ... END OF T. MODULE LINE_IN OUTPUT. MODIFY TABLE T INDEX CURPOS. ENDMODULE. |
Note: for the functionality "position in the list", the field that is used as cursor (CURPOS in the example) can also be placed on the screen directly as an input field (type INT4. The end user could then type the line number he/she would like to go to.
Hint: use LOOP AT
or use a structure that saves all non-screen fields temporarily via two MOVE-CORRESPONDING
's.