GET REFERENCE OF Select-Options INTO range table

[Former Member]

Hello gurus,

Does anyone know why I cannot get the refence of a Select-Options into a range table?

Example:

TYPES: ty_r_matnr TYPE RANGE OF matnr.

DATA: lv_matnr TYPE        matnr,
      lr_matnr TYPE REF TO ty_r_matnr.

SELECT-OPTIONS: s_matnr FOR lv_matnr.


AT SELECTION-SCREEN OUTPUT.

  GET REFERENCE OF s_matnr[] INTO lr_matnr.

This previous code does not compile.

Thanks a lot!,

Eloi

[antoine_foucault]

Hi:

You're issue is that lr_matnr is type ty_r_matnr which is a structure not a table thus you try to assign the reference of a table to it.... 🙂

That should do the trick:

TYPES: ty_t_matnr type table of ty_r_matnr

DATA: lr_matnr type ref to ty_t_matnr

Best,

Antoine

[horst_keller]

Hmm, in fact TYPE RANGE OF does declare a table type

[antoine_foucault]

Yes exactly TYPE RANGE OF declare a structure.... my solution does not compile either... "you cannot reference a generic type" :).... let see for your find out tomorrow !

[horst_keller]

No, RANGE OF declares a table, not a structure.

[antoine_foucault]

You are absolutely right, my mistake... TYPE RANGE OF declares a tables... seems I was mistaken since the beginning.... thank you for the solution Horst.

[horst_keller]

The problem seems to be, although having the same components, the types of the ranges table and the body of the selection table are regarded as different.

I'll look into that tomorrow. Because according to http://help.sap.com/abapdocu_751/en/index.htm?file=abenconversion_references_data.htm and the documentation of GET REFERENCE one might expect it to work.

Independent of that, a

DATA dref LIKE REF TO seltab[ ] should work.

[horst_keller]

I tend to think that you found a bug. Your program should work as written above.

I tested as follows:

DATA number TYPE i.
TYPES: BEGIN OF linetype,
         sign   TYPE c LENGTH 1,
         option TYPE c LENGTH 2,
         low    LIKE number,
         high   LIKE number,
       END OF linetype.

DATA range1 LIKE RANGE OF number.
DATA range2 TYPE TABLE OF linetype.
DATA range3 TYPE TABLE OF linetype WITH HEADER LINE.
SELECT-OPTIONS seltab FOR number.

DATA dref1 LIKE REF TO range1.
DATA dref2 LIKE REF TO range2.
DATA dref3 LIKE REF TO range3[].
DATA dref4 LIKE REF TO seltab[].

"GET REFERENCE OF seltab[] INTO dref1. "Syntax error
"GET REFERENCE OF seltab[] INTO dref2. "Syntax error
"GET REFERENCE OF seltab[] INTO dref3. "Syntax error
GET REFERENCE OF seltab[] INTO dref4. "OK

dref1 = dref4. "OK
dref2 = dref4. "OK
dref3 = dref4. "OK

BREAK-POINT.

Since you can assign the reference to the table body of seltab via an up cast to the reference variables of ranges tables, this should also work directly with GET REFERENCE.

B.t.w., it is not because of the header line.

DATA itab1 TYPE TABLE OF scarr.
DATA itab2 TYPE TABLE OF scarr WITH HEADER LINE.

DATA dref1 LIKE REF TO itab1.
DATA dref2 LIKE REF TO itab2[].

GET REFERENCE OF itab2[] INTO dref1. "OK
GET REFERENCE OF itab2[] INTO dref2. "OK

I'll report the strange behavior to kernel development.

Thanks for notifying.

[horst_keller]

PS:

The workaraound for you should be clear:

SELECT-OPTIONS: s_matnr FOR lv_matnr.
DATA lr_matnr LIKE REF TO s_matnr[].

AT SELECTION-SCREEN OUTPUT.

  GET REFERENCE OF s_matnr[] INTO lr_matnr.

Besides, there is some discussion going on here.

The point is, that SELECT-OPTIONS internally declares an own structure and it is documented for the up cast, that

"In the case of structured types, identical technical type attributes are not sufficient and, in the ...."

The up cast is prerequisite for GET REFERENCE and therefore, you get the error. Quite clear now.

But it is not clear why the three assignments dref1 = dref4, ... above work! That lead me on the wrong track. And if you

would do the same for structures, it doesn't work. -> Weaker check of up cast rules for internal tables compared to structures in assignments but not in GET REFERENCE, oh my.

[Sandra_Rossi]

It's related to structured types, not specifically to select-options. Two abap standalone structured types have distinct bound data types (it's not documented, it's what I have seen). So the following code has the same issues:

 TYPES number TYPE i.
 TYPES: BEGIN OF structype,
   low TYPE number,
 END OF structype.
 TYPES: BEGIN OF structype2,
   low TYPE number,
 END OF structype2.

 DATA struc1 TYPE structype2.
 DATA struc1b TYPE structype2.
 DATA struc2 TYPE structype.

 DATA dref1 LIKE REF TO struc1.
 DATA dref2 LIKE REF TO struc2.

* GET REFERENCE OF struc1 INTO dref2. "Syntax error
* GET REFERENCE OF struc2 INTO dref1. "Syntax error
 GET REFERENCE OF struc1b INTO dref1. "OK

* dref1 = dref2. "Syntax error

I think this is a behavior since at least release 7.0.

[horst_keller]

Hi Sandra,

In fact this is documented and expected behavior.

And it is exactly the same for structured internal tables. For GET REFERENCE, parameter passing, dynamic assignments, ...

The bug that crept in, is that the check for internal tables (not for structures) became lax in static assignments with = resp. MOVE (and only there). There, only the technical properties are checked.

Horst

[Sandra_Rossi]

Ouch! Thanks for pointing me to the right direction! I thought I had given some different information. I don't even understand what means "up cast" here. I need to read your answer and the documentation around 100 times, and then MAYBE I can understand 🙂

[horst_keller]

Yeah, kind of confusing. We even had a meeting about that today to get our thoughts straight.

Up and down cast come into play, because assignments of data reference variables are treated exactly like those of object reference variables. And since we have only one "generic" type, DATA, for data references, all other types must be exactly the same for assignable data reference variables (remember, object reference variables of classes from different inheritance trees cannot be assigned, even if the classes have exactly the same components).

This design decision might be questionable, a cast for data references could also be something else, but that's how it is.

[Sandra_Rossi]

I can reproduce the bug in ABAP 7.31 and 7.40 (kernel 742 for the latter).