CLEAR

The CLEAR statement simply resets the contents of a data variable or field to its
default value. For a character field this means all spaces, while number fields are
reset to zero.
For example, if you have declared a data variable as follows:
DATA: CITY(20) VALUE ‘BRISBANE’.

Then the CITY variable contains “Brisbane “. If you then use a clear
statement:
CLEAR CITY.
The CITY variable now contains 20 spaces only.

As well as begin able to clear data variables, the CLEAR statement can also be
used to clear either individual fields of workareas, whole workareas, or whole
internal tables.

Say we have declared these structures:

DATA: ITAB LIKE SPFLI OCCURS 100 WITH HEADER LINE,
WA LIKE SPFLI.
Then all the following statements are valid:
* reset some workarea fields to defaults
CLEAR: WA-CONNID, WA-CITYFROM.

* reset the whole workarea

CLEAR WA.

* reset some header line fields

CLEAR ITAB-CARRID, ITAB-CITYFROM, ITAB-CITYTO.

* reset the whole header line

CLEAR ITAB.

* reset the whole internal table

CLEAR ITAB[].

* another way to reset the whole internal table

REFRESH ITAB.

Note that if you have declared an internal table with a header line, then in the
CLEAR ITAB statement, ITAB refers to the header line, not the internal table, so
you need to use one of the last two statements in the examples to actually clear
the internal table. If you have declared an internal table without a header line,
then there is no confusion with the CLEAR ITAB statement: in this case ITAB can
only refer to the whole internal table.

HIDE

The HIDE statement is used to reserve certain values for each row output to a
list. You hide those fields on which you intend to base data selections in later
secondary lists. You might imagine that the field values that are named in the
HIDE statement are listed invisibly to the right of each row in the list.

When a user selects a row and triggers an AT LINE_SELECTION event (either by

double click, or via the relevant toolbar button, menu item or function key), those
values hidden for that row are first copied back into the workarea that was used
to write the list, and then read from there in the SELECT statement used to write
the next secondary list.

For example, the following code writes a simple list (note that the SPFLI referred
to in the WRITE and HIDE statements is the default workarea for the table, not
the table itself):

SELECT * FROM SPFLI.

WRITE: / SPFLI-CONNID, SPFLI-CITYFROM,
SPFLI-CITYTO.
HIDE: SPFLI-CARRID, SPFLI-CONNID.
ENDSELECT.

This code results in a list that looks something like this:

SPFLI-CARRID SPFLI-
CONNID
1223 BRISBANE PERTH AA 1223
2407 SYDNEY BRISBANE AA 2407
2222 LONDON BRISBANE QF 2222

Note the last two fields in each row are hidden (and are invisible to the user).
Note also that you can hide fields other than those written out, if you wish (in this
example, we have hidden SPFLI-CARRID even though that field is not written to
the visible part of the list).

Now, say the user double clicks on the second row of the list. The first thing that
happens is that the hidden value ‘AA’ is copied to the CARRID field of the SPFLI
workarea, and the hidden value ‘2407’ is copied to the CONNID field of the SPFLI
workarea. Once all the hidden values for the selected row are copied back into
the workarea they were originally written from, the program will then execute the
code under the AT LINE-SELECTION event.

Somewhere in the code for the AT LINE-SELECTION event there will be a SELECT
statement that selects the data to write to the next secondary list based on the
hidden values copied into the relevant workarea. In this example, it may be
something like this:

SELECT * FROM SFLIGHT

WHERE CARRID = SPFLI-CARRID
AND CONNID = SPFLI-CONNID.

WRITE: SFLIGHT-FLDATE, SFLIGHT-ARRTIME, ...

HIDE SFLIGHT-FLDATE.
ENDSELECT.

CLEAR & HIDE as a team

So where does CLEAR fit in? You use CLEAR to ensure that at all times when a
query contains a hidden field value, that field contains the correct and expected
data.

Consider the examples above. If the user double clicks on a valid row, the correct
data is copied from the hidden fields for that row to the workarea, from where it
is used in the SELECT statement for the next secondary list. But what happens if
the user double clicks on somewhere other than a valid row, say in the list
header? What values are used then?

Well, since there are no hidden field values in the header, no copy to the
workarea takes place, and so the SELECT statement will use the data that was
already contained in the workarea previously. In this example, the SPFLI
workarea still contains the last SPFLI row written to the list, so the SELECT
statement for the secondary list will use the values ‘QF’ for CARRID and ‘2222’ for
CONNID. This will result in a secondary list that has no relation to the data area
the user selected (i.e. the list header).

However, if you CLEAR the workarea immediately after you finish the data
selection, then the workarea fields are reset back to defaults, and won’t contain
the values for the last row written out to the list.

So, if we change the first block of code to insert a clear statement like this:

SELECT * FROM SPFLI.

WRITE: / SPFLI-CONNID, SPFLI-CITYFROM,
SPFLI-CITYTO.
HIDE: SPFLI-CARRID, SPFLI-CONNID.
ENDSELECT.
CLEAR: SPFLI-CARRID, SPFLI-CONNID.

then the relevant workarea fields are reset to blanks and zero respectively.
Finally, when an AT LINE-SELECTION event is triggered, we can check for valid
data in the workarea in our second block of code like this:

* write secondary list only if carrid has data

IF NOT SPFLI-CARRID IS INITIAL.
SELECT * FROM SFLIGHT
WHERE CARRID = SPFLI-CARRID
AND CONNID = SPFLI-CONNID.

WRITE: SFLIGHT-FLDATE, SFLIGHT-ARRTIME, ...

HIDE SFLIGHT-FLDATE.
ENDSELECT.
CLEAR SFLIGHT-FLDATE.
ENDIF.

Now as we move through the screens, all we have to do is, immediately after the
select loop, clear the same fields that we have hidden within the loop. Then, in AT
LINE-SELECTION, we simply test to make sure the field is not still cleared – if it
is, the user has not selected a valid list line; if it has data, then the user has
selected a valid list line.

But that’s fine for moving forward through the secondary lists. What about when
we move back through the screens? For example, if we go back from the
SFLIGHT secondary list created above to the SPFLI list we created with the first
block of code, then the SPFLI workarea still contains the data used to build the
SFLIGHT secondary list! If the user double clicks on the header of the SPFLI list,
then the previously selected data is used again to create an identical SFLIGHT
list, even though the user hasn’t selected a valid list line on this occasion. So we
have to take care to clear the relevant fields when moving forwards OR
backwards through the lists.
There’s a pretty simple rule to follow here. As well as clearing the fields we hide
in the loop to facilitate moving forward, we also need to clear the fields used in
the WHERE clause of the SELECT statement to facilitate moving backwards.

Following our example, we simply make the follow change:

* write secondary list only if carrid has data

IF NOT SPFLI-CARRID IS INITIAL.
SELECT * FROM SFLIGHT
WHERE CARRID = SPFLI-CARRID
AND CONNID = SPFLI-CONNID.

WRITE: SFLIGHT-FLDATE, SFLIGHT-ARRTIME, ...

HIDE SFLIGHT-FLDATE.
ENDSELECT.

* clear fields from both HIDE and WHERE

CLEAR: SFLIGHT-FLDATE,
SPFLI-CARRID, SPFLI-CONNID.
ENDIF.

Once the SELECT statement (or loop) has completed, the values used in the
WHERE clause are no longer required and so can be safely cleared in readiness
for future selections if the user moves back and then forward between screens.

So in summary, always follow these rules when working with multiple interactive
lists:

1. HIDE those fields whose values will be used in following selections.

2. Immediately after the SELECT statement (or loop) has completed, CLEAR
the fields specified in the HIDE statement AND the fields used in the
WHERE clause of the SELECT statement.

3. Test one of the relevant fields in the AT LINE-SELECTION event to ensure

the fields to be used in the SELECT statement contain valid data (using IF
NOT … IS INITIAL).