Die gefüllte interne Tabelle an Form als parameter weitergeben.

Die gefüllte interne Tabelle an Form als parameter weitergeben.

Hallo,

ich habe eine interne Tabelle, die schon gefüllt ist (lt_split).

wenn ich die Tabelle (lt_split) mit Perform an Form weitergebe, die Tabelle im Form ist leer. Warum?

TYPES: BEGIN OF t_split,
customer(10) TYPE c,
material(10) TYPE c,
purchaseorder(10) TYPE c,
wunschlieferdatum(10) TYPE c,
menge(5) TYPE c,
werk(5) TYPE c,
END OF t_split.

DATA: lt_split TYPE TABLE OF t_split,
ls_split LIKE LINE OF lt_split.

DATA: lv_order_nr TYPE vbeln.
...
<Die Tabelle lt_split wurde mit Daten gefüllt>
...

PERFORM create_order USING lt_split CHANGING lv_order_nr.

Form create_order USING lt_split CHANGING lv_order_nr TYPE vbeln.

...

Endform.

Danke im Voraus!
Vg

Re: Die gefüllte interne Tabelle an Form als parameter weitergeben.

du verschattest die Variable lt_split in der FORM-Routine!!
benenne den Parameter um in it_split, dann funktioniert es auch.

Re: Die gefüllte interne Tabelle an Form als parameter weitergeben.

Stimmt, das mit der Verschattung ist Quatsch.
Das andere aber auch.
Folgendes Coding funktioniert einwandfrei:

Re: Die gefüllte interne Tabelle an Form als parameter weitergeben.

das ist ja "cool"...
der cl_demo_output nimmt die korrekte Tabelle LT_SPLIT.
Als LOOP meckert der Compiler: LT_SPLIT ist keine interne Tabelle. Klar, weil er das zur Laufzeit auch nicht wissen kann, denn der USING-Parameter ist untypisiert.

Korrekt muss es also heißen: Und ganz korrekt sollte der Using-Parameter natürlich IT_SPLIT heißen... ;)

Re: Die gefüllte interne Tabelle an Form als parameter weitergeben.

ewx hat geschrieben: ↑

27.04.2023 12:02

das ist ja "cool"...
der cl_demo_output nimmt die korrekte Tabelle LT_SPLIT.
Als LOOP meckert der Compiler: LT_SPLIT ist keine interne Tabelle. Klar, weil er das zur Laufzeit auch nicht wissen kann, denn der USING-Parameter ist untypisiert.

Richtig, das Verhalten ist erwartungsgemäß. In dem Moment, in dem man statisch über einen Parameter LOOPen möchte, muss man ihn auch als Parameter typisieren. Für Faule hätte es freilich ausgereicht, den USING-Parameter per TYPE ANY TABLE zu deklarieren (jedenfalls solange man statisch nicht auf konkrete Spalten zugreifen möchte). Besser ist natürlich das, was Du gemacht hast.

black_adept hat geschrieben:Und da USING-Parameter auch geändert werden können, sollte man lieber auf USING verzichten und gleich CHANGING nehmen

Finde ich nicht. Es ist zwar schade, dass ABAP das Ändern von USING-Parametern zumindest in statischer Form nicht verhindert, aber dennoch kann man als Programmierer mit USING dem Leser kommunizieren, welche Verwendung des Parameters angedacht (bzw. nicht angedacht) ist. CHANGING hingegen kommuniziert explizit, dass eine Änderung des Parameters in der Unterroutine vorgesehen ist. Daher halte ich CHANGING für verwirrend und nicht ratsam, wenn die Unterroutine den Parameter nur nutzen und nicht ändern soll.

Aber ja, die hässliche USING/CHANGING-Bauform von Formroutinen sind ein wesentlicher Grund, weshalb Methodenaufrufe sich bedeutend verständlicher lesen und damit drastisch zur Lesbarkeit des Codes beitragen. Schade, dass man bei Methoden dafür so einen Wasserkopf eingebaut hat, der es unnötig aufwendig macht, sie zu programmieren. Das hätte man besser lösen können.