Code: Alles auswählen.
CLASS-METHODS test_methode IMPORTING it_table type standard table.
Code: Alles auswählen.
mt_table type standard table.
Code: Alles auswählen.
DATA mt_table type ref to data.
FIELD-SYMBOLS <fs_table> type standard table.
ASSIGN me->mt_table->* TO <fs_table>.
<fs_table> = it_table
Code: Alles auswählen.
DATA mt_table type ref to data.
FIELD-SYMBOLS <fs_table> type standard table.
CREATE DATA mt_table LIKE it_table.
ASSIGN me->mt_table->* TO <fs_table>.
<fs_table> = it_table
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
abapnewbie
Code: Alles auswählen.
GET REFERENCE OF it_table INTO me->mt_table.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
abapnewbie
Vielen Dank, deine Lösung hat wie gewünscht funktioniert! Meine Membervariable wird nun richtig befüllt.a-dead-trousers hat geschrieben: ↑27.01.2020 20:33Sofern du die Daten nicht wirklich "kopieren" musst, kannst du auch mit einer direkten Referenz auf die Originaldaten arbeiten.Dabei musst du aber aufpassen, dass die Referenz die "Eigenschaften" des Methoden-Parameters erbt. D.h. bei einem IMPORTING ist die Referenz me->mt_table "Read-Only". Um einen schreibenden Zugriff zu haben musst du den Paramter als CHANGING deklarieren.Code: Alles auswählen.
GET REFERENCE OF it_table INTO me->mt_table.
Ja.abapnewbie hat geschrieben: ↑28.01.2020 08:28Zum Verständnis noch mal: Wenn ich die Tabelle also über IMPORTING in die Klasse übergebe und dann eine mit mt_table darauf referenziere kann ich die mt_table nur lesen. Wenn ich hingegen statt IMPORTING CHANGING nehme, dann kann ich die mt_table auch editieren?
Oh das habe ich jetzt im Debugger auch gemerkt.. Das wird dann aber leider keine Lösung für mein Problem sein, da ich die Daten dieser Tabelle später noch sortieren und filtern möchte. Sobald ich in die Methode abspringe um ein FuBa aufzurufen, löst sich die Referenz tatsächlich wieder.a-dead-trousers hat geschrieben: ↑28.01.2020 09:52Ja.abapnewbie hat geschrieben: ↑28.01.2020 08:28Zum Verständnis noch mal: Wenn ich die Tabelle also über IMPORTING in die Klasse übergebe und dann eine mit mt_table darauf referenziere kann ich die mt_table nur lesen. Wenn ich hingegen statt IMPORTING CHANGING nehme, dann kann ich die mt_table auch editieren?
Eines gilt es noch zubeachten: Wenn du eine in einer anderen Methode definierte Variable an deine Methode übergibst, ist die Referenz nach Verlassen der ersten Methode nicht mehr gültig.
Die erste Variante die ich gepostet hab mit der echten Kopie.abapnewbie hat geschrieben: ↑28.01.2020 11:18Welche Möglichkeit hätte ich denn die Daten der Tabelle permanent in der mt_table zu speichern?
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
abapnewbie
Wenn du jegliche Tabelle übergeben willst müsstest du aber stattdessen "ANY TABLE" verwenden.abapnewbie hat geschrieben: ↑27.01.2020 19:42[...]Ich habe eine Methode der ich gerne jegliche Tabelle übergeben würde, daher hat der Parameter den Typ STANDARD TABLE.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
abapnewbie
Ich bin nicht sicher, ob ich da eine Schwäche in meinem OO-Verständnis habe oder ob hier ein Widerspruch vorliegt, aber ein Konstruktur dient doch dazu, neue Objektinstanzen zu initialisieren. Eine statische Klasse hat aber doch gar keine Objektinstanzen, sondern funktioniert ähnlich wie ein Funktionsbaustein. Wozu also ein Konstruktor?Das ganze ist eine statische Klasse was dann durch andere Z-Programme aufgerufen werden soll. Jetzt würde ich gerne für den weiteren Verlauf in der Klasse objektorientiert programmieren und habe mir ein paar Member-Variablen im Konstruktor zugelegt.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
abapnewbie
Habe mich verschrieben, innerhalb der Klasse wird natürlich OO-Programmiert. Die Klasse soll einem Export dienen und dementsprechend soll die "Hauptmethode" statisch aufrufbar sein. Quasi klassenname=>hauptmethode ( it_table = irgendeine tabelle die exportiert werden soll). Innerhalb der Klasse wird dann in dieser Methode eine Instanz erzeugt und dann weiter programmiert. Das Problem entsteht dabei, wenn ich nun versuche diese it_table in einer Membervariable abzuspeichern. Die Lösung:DeathAndPain hat geschrieben: ↑28.01.2020 12:52Ich bin nicht sicher, ob ich da eine Schwäche in meinem OO-Verständnis habe oder ob hier ein Widerspruch vorliegt, aber ein Konstruktur dient doch dazu, neue Objektinstanzen zu initialisieren. Eine statische Klasse hat aber doch gar keine Objektinstanzen, sondern funktioniert ähnlich wie ein Funktionsbaustein. Wozu also ein Konstruktor?Das ganze ist eine statische Klasse was dann durch andere Z-Programme aufgerufen werden soll. Jetzt würde ich gerne für den weiteren Verlauf in der Klasse objektorientiert programmieren und habe mir ein paar Member-Variablen im Konstruktor zugelegt.
Code: Alles auswählen.
GET REFERENCE OF it_table INTO me->mt_table.
Hat adt doch schon gepostet: viewtopic.php?f=3&t=24142#p94643abapnewbie hat geschrieben: ↑28.01.2020 13:27Allerdings würde mich trotzdem eine Lösung interessieren, falls dieses Problem in Zukunft erneut auftaucht.
Wo genau liegt der Vorteil der statischen Programmierung, wenn die Methode - und so habe ich Dich verstanden - aus nicht mehr besteht als einer Schale, die eine Instanz daraus macht? Weshalb sollte es für rufende Programme einfacher sein, nicht selbst mit der instanziierten Methode zu arbeiten?Die Klasse soll einem Export dienen und dementsprechend soll die "Hauptmethode" statisch aufrufbar sein.
[...]
Ich habe mich entschieden für diese Lösung speziell die Methoden alle statisch zu programmieren, da ich sie so einfacher wiederverwenden kann.