Von der ALV-Liste zum Objekt...
Hi!
Hab eine Anfängerfrage bezüglich ABAP OO.
Wenn ich prozedural programmiere und mit GET_SELECTED_ROWS auf meine ALV-Zeile zugreife, so bekomme ich ja sofort meine entsprechende Zeile und kann damit arbeiten..
Wenn ich allerdings den Weg über ABAP OO gehe, wie komme ich dann über die ALV-Zeile schnell an mein entsprechendes Objekt? Ich finde es doch sehr umständlich, die entsprechende Zeile im ALV zurückzugeben, dann meine gesamte Objektliste durchgehen zu müssen, um zu schauen, welches Objekt ich durch die selektierte Zeile eigentlich in der Hand habe.
Hoffe euch ist klar was ich meine. Gibts da eine "elegantere" Variante?
Viel Grüße
Hab eine Anfängerfrage bezüglich ABAP OO.
Wenn ich prozedural programmiere und mit GET_SELECTED_ROWS auf meine ALV-Zeile zugreife, so bekomme ich ja sofort meine entsprechende Zeile und kann damit arbeiten..
Wenn ich allerdings den Weg über ABAP OO gehe, wie komme ich dann über die ALV-Zeile schnell an mein entsprechendes Objekt? Ich finde es doch sehr umständlich, die entsprechende Zeile im ALV zurückzugeben, dann meine gesamte Objektliste durchgehen zu müssen, um zu schauen, welches Objekt ich durch die selektierte Zeile eigentlich in der Hand habe.
Hoffe euch ist klar was ich meine. Gibts da eine "elegantere" Variante?
Viel Grüße
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
hmmm... Ganz hab ich dich nicht verstanden.
GET_SELECTED_ROWS ist ja die Methode mit der man die markierten Zeilen ermittelt. Im Ergebnis stehen die Index-Positionen drinnen und damit kannst du aus der internen Tabelle die du mit SET_TABLE_FOR_FIRST_DISPLAY an das ALV geschickt hast die entsprechenden Zeilen auslesen.
Das funktioniert "prozedural" genauso wie auch im OO.
Was genau meinst du mit Objektliste?
lg ADT
hmmm... Ganz hab ich dich nicht verstanden.
GET_SELECTED_ROWS ist ja die Methode mit der man die markierten Zeilen ermittelt. Im Ergebnis stehen die Index-Positionen drinnen und damit kannst du aus der internen Tabelle die du mit SET_TABLE_FOR_FIRST_DISPLAY an das ALV geschickt hast die entsprechenden Zeilen auslesen.
Das funktioniert "prozedural" genauso wie auch im OO.
Was genau meinst du mit Objektliste?
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hi!
Mit Objektliste meine ich eine Liste von Objekten: Ich habe eine Klasse A, dort besitzt ein Objekt eine interne Tabelle mit Objekten der Klasse B. Ein Objekt der Klasse B hat wiederum eine interne Tabelle mit Objekten der Klasse C. --> 1:n -Beziehungen
Das Problem an meiner ALV-Liste ist, dass diese Informationen beinhaltet aus einem Objekt der Klasse B und aus einem Objekt der Klasse C.
Wenn der Anwender nun eine Zeile im ALV löscht, so muss jedoch lediglich ein Objekt der Klasse C gelöscht werden. Wie komm ich aber nun am besten an dieses Objekt? (das war meine eigentliche Frage)
Prozedural könnte ich ja einfach diese Zeile löschen, da ich durch GET_SELECTED_ROWS die exakte Zeile habe. Wenn ich jetzt aber objektorientiert vorgehe und dabei meine Klassenstruktur berücksichtige, dann müsste ich doch die Objektliste von Objekten der Klasse A durchloopen und die Objektliste von Objekten der Klasse B durchloopen, um an das bestimmte Objekt der Klasse C zu gelangen, welches ich löschen möchte. Das wäre halt ein enormer Aufwand...
Ist es jetzt verständlich was ich meine? Muss ich so vorgehen oder habe ich was gar nicht bedacht?
Viele Grüße
Mit Objektliste meine ich eine Liste von Objekten: Ich habe eine Klasse A, dort besitzt ein Objekt eine interne Tabelle mit Objekten der Klasse B. Ein Objekt der Klasse B hat wiederum eine interne Tabelle mit Objekten der Klasse C. --> 1:n -Beziehungen
Das Problem an meiner ALV-Liste ist, dass diese Informationen beinhaltet aus einem Objekt der Klasse B und aus einem Objekt der Klasse C.
Wenn der Anwender nun eine Zeile im ALV löscht, so muss jedoch lediglich ein Objekt der Klasse C gelöscht werden. Wie komm ich aber nun am besten an dieses Objekt? (das war meine eigentliche Frage)
Prozedural könnte ich ja einfach diese Zeile löschen, da ich durch GET_SELECTED_ROWS die exakte Zeile habe. Wenn ich jetzt aber objektorientiert vorgehe und dabei meine Klassenstruktur berücksichtige, dann müsste ich doch die Objektliste von Objekten der Klasse A durchloopen und die Objektliste von Objekten der Klasse B durchloopen, um an das bestimmte Objekt der Klasse C zu gelangen, welches ich löschen möchte. Das wäre halt ein enormer Aufwand...
Ist es jetzt verständlich was ich meine? Muss ich so vorgehen oder habe ich was gar nicht bedacht?
Viele Grüße
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
Stell in jede Zeile der Tabelle die du im ALV anzeigst zusätzliche Felder in denen du Referenzen auf die jeweiligen Klassen ablegst.
Die Anzeige dieser Felder verhinderst du indem du im Feldkatalog entweder auf TECH = 'X' (technisch) setzt oder den Eintrag überhaupt wegläst.
Damit hast du zu jeder Zeit die Informationen die du für die Weiterverarbeitung benötigst.
lg ADT
Stell in jede Zeile der Tabelle die du im ALV anzeigst zusätzliche Felder in denen du Referenzen auf die jeweiligen Klassen ablegst.
Die Anzeige dieser Felder verhinderst du indem du im Feldkatalog entweder auf TECH = 'X' (technisch) setzt oder den Eintrag überhaupt wegläst.
Damit hast du zu jeder Zeit die Informationen die du für die Weiterverarbeitung benötigst.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hi!
Wenn ich das richtig verstehe, dann muss ich sowohl meinen Feldkatalog um ein paar Spalten
erweitern, die ich nicht anzeige, als auch meine interne Tabelle, die ich der Methode set_table_for_first_display übergebe. Diese Tabelle bräuchte ja dann
Referenzen meiner Klassen? Stimmt das?
Derzeit loope ich meine Objektlisten durch, um mir die Werte in eine Struktur zu füllen und daraus meine ALV zu basteln.
Diesem ALV würde ich dann aber wieder Felder zuweisen, die über Referenzen der Klassen verfügen? Habe ich das richtig verstanden?
Falls ja, erzeugt das nicht einen ziemlichen Overhead?
Außerdem dachte ich, mann kann dem ALV keine Referenzen übergeben? Oder setzt man
aus diesem Grund TECH = 'X'?
Hättest du mir vllt. ein kurzes Beispiel?
Vielen Dank für deine Hilfe und viele Grüße
Wenn ich das richtig verstehe, dann muss ich sowohl meinen Feldkatalog um ein paar Spalten
erweitern, die ich nicht anzeige, als auch meine interne Tabelle, die ich der Methode set_table_for_first_display übergebe. Diese Tabelle bräuchte ja dann
Referenzen meiner Klassen? Stimmt das?
Derzeit loope ich meine Objektlisten durch, um mir die Werte in eine Struktur zu füllen und daraus meine ALV zu basteln.
Diesem ALV würde ich dann aber wieder Felder zuweisen, die über Referenzen der Klassen verfügen? Habe ich das richtig verstanden?
Falls ja, erzeugt das nicht einen ziemlichen Overhead?
Außerdem dachte ich, mann kann dem ALV keine Referenzen übergeben? Oder setzt man
aus diesem Grund TECH = 'X'?
Hättest du mir vllt. ein kurzes Beispiel?
Vielen Dank für deine Hilfe und viele Grüße
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
hi!
Alles richtig! Mit Ausnahme des Overheads. Eine Referenzvariable hat intern 8 Byte und die sind verschmerzbar. Der Overhead jedesmal nach der richtigen Instanz zu suchen wiegt sicherlich schwerer. Eigentlich brauchst du die zusätzlichen Felder auch nicht im Feldkatalog.
Ich nehme mal an du verwendest die LVC_FIELDCATALOG*- Bausteine um die interne Tabelle für die Ausgabe zu erstellen.
Die glaub ich können sowieso nicht mit Referenzen umgehen, vom ALV ganz zu schweigen
Ne, was du braucht sind die RTTI-Klassen.
Mit meinem Beispiel als Grundlage kannst du dir die LT_COMPONENTS aller verwendeten Strukturen ermitteln. Diese Komponenten-Tabelle erweiterst du dann noch um zusätzliche Zeilen (Felder) für die Speicherung der jeweiligen Klassen(-Instanzen).
Das Ergebnis geht dann an den CL_ABAP_STRUCTDESCR=>CREATE und dessen Ergebnis an den CL_ABAP_TABLEDESCR=>CREATE.
voilà, jetzt hast du die fertige Tabellenbeschreibung für deine interne Tabelle.
CREATE DATA ... TYPE HANDLE ... und die interne Tabelle ist auch angelegt.
Und wenn du dir das Erstellen des Feldkataloges sparen willst, kannst statt dem ALV den CL_SALV_TABLE verwenden.
lg ADT
Alles richtig! Mit Ausnahme des Overheads. Eine Referenzvariable hat intern 8 Byte und die sind verschmerzbar. Der Overhead jedesmal nach der richtigen Instanz zu suchen wiegt sicherlich schwerer. Eigentlich brauchst du die zusätzlichen Felder auch nicht im Feldkatalog.
Ich nehme mal an du verwendest die LVC_FIELDCATALOG*- Bausteine um die interne Tabelle für die Ausgabe zu erstellen.
Die glaub ich können sowieso nicht mit Referenzen umgehen, vom ALV ganz zu schweigen
Ne, was du braucht sind die RTTI-Klassen.
Mit meinem Beispiel als Grundlage kannst du dir die LT_COMPONENTS aller verwendeten Strukturen ermitteln. Diese Komponenten-Tabelle erweiterst du dann noch um zusätzliche Zeilen (Felder) für die Speicherung der jeweiligen Klassen(-Instanzen).
Das Ergebnis geht dann an den CL_ABAP_STRUCTDESCR=>CREATE und dessen Ergebnis an den CL_ABAP_TABLEDESCR=>CREATE.
voilà, jetzt hast du die fertige Tabellenbeschreibung für deine interne Tabelle.
CREATE DATA ... TYPE HANDLE ... und die interne Tabelle ist auch angelegt.
Und wenn du dir das Erstellen des Feldkataloges sparen willst, kannst statt dem ALV den CL_SALV_TABLE verwenden.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hi!
Bisher hatte ich mir die Instanz der Klasse A erzeugt. Diese verfügt über eine itab mit Referenzen
der Klasse B. Dazu hab ich in Klasse B auf die DB zugegriffen und die entsprechenden Werte ermittelt.
Das gleiche dann mit Referenzen der Klasse C, die einer Referenz der Klasse B zugewiesen sind.
Was ich nun bisher gemacht hatte war ja, das ich mir die Instanz der Klasse A geholt hab
und das dann alles durchgeloopt hab. Das blöde nun ist, dass ich nun zwei ALVs ausgeben möchte,
allerdings beinhalten beide Daten sowohl von Klasse B als auch von Klasse C. =/
Das hab ich dann mit echt hässlichen Loops gemacht, so dass ich nun die beiden ALVs habe,
die jeweils Zeilen besitzen mit Informationen aus Klasse B und C.
Du meinst also, mit den RTTI-Klassen kann ich mir das durchloopen schenken?
Ich seh da irgendwie Probleme bei der Verschachtelung.
Hinzu kommt, dass mein Ausgangspunkt ja keine Struktur oder interne Tabelle ist, sondern eine Referenz
der Klasse A. Diese möchte ich nun "auflösen" und deren Inhalte in zwei ALVs übertragen.
Puh...du merkst vllt. schon, dass mir die Sache (noch) nicht so ganz klar ist.
Würde mich über weitere Hilfe sehr freuen. Find ich ohnehin super, wie aktiv du hier im Forum bist.
Vielen Dank!!
Nein, ich verwende die Struktur LVC_S_FCAT und häng mittels APPEND meine itab dran.a-dead-trousers hat geschrieben: Ich nehme mal an du verwendest die LVC_FIELDCATALOG*- Bausteine um die interne Tabelle für die Ausgabe zu erstellen.
Die glaub ich können sowieso nicht mit Referenzen umgehen, vom ALV ganz zu schweigen
Meine ALV soll editierbar sein und ich meine gelesen zu haben, dass das von CL_SALV_TABLE nicht unterstützt wird.a-dead-trousers hat geschrieben: Und wenn du dir das Erstellen des Feldkataloges sparen willst, kannst statt dem ALV den CL_SALV_TABLE verwenden.
Habe mal das von dir erstellte Programm bei mir eingebaut. So ganz steig ich noch nicht dahinter.a-dead-trousers hat geschrieben: Ne, was du braucht sind die RTTI-Klassen.
Mit meinem Beispiel als Grundlage kannst du dir die LT_COMPONENTS aller verwendeten Strukturen ermitteln. Diese Komponenten-Tabelle erweiterst du dann noch um zusätzliche Zeilen (Felder) für die Speicherung der jeweiligen Klassen(-Instanzen).
Bisher hatte ich mir die Instanz der Klasse A erzeugt. Diese verfügt über eine itab mit Referenzen
der Klasse B. Dazu hab ich in Klasse B auf die DB zugegriffen und die entsprechenden Werte ermittelt.
Das gleiche dann mit Referenzen der Klasse C, die einer Referenz der Klasse B zugewiesen sind.
Was ich nun bisher gemacht hatte war ja, das ich mir die Instanz der Klasse A geholt hab
und das dann alles durchgeloopt hab. Das blöde nun ist, dass ich nun zwei ALVs ausgeben möchte,
allerdings beinhalten beide Daten sowohl von Klasse B als auch von Klasse C. =/
Das hab ich dann mit echt hässlichen Loops gemacht, so dass ich nun die beiden ALVs habe,
die jeweils Zeilen besitzen mit Informationen aus Klasse B und C.
Du meinst also, mit den RTTI-Klassen kann ich mir das durchloopen schenken?
Ich seh da irgendwie Probleme bei der Verschachtelung.
Hinzu kommt, dass mein Ausgangspunkt ja keine Struktur oder interne Tabelle ist, sondern eine Referenz
der Klasse A. Diese möchte ich nun "auflösen" und deren Inhalte in zwei ALVs übertragen.
Puh...du merkst vllt. schon, dass mir die Sache (noch) nicht so ganz klar ist.
Würde mich über weitere Hilfe sehr freuen. Find ich ohnehin super, wie aktiv du hier im Forum bist.
Vielen Dank!!
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
achsoooo...
Du hast so ne Art SDO gemacht, wo jede Klasse einer DB-Tabelle entspricht und jedes Objekt der Klassen einer jeweiligen Zeile.
Wie hast du die interne Struktur/Tabelle für die Anzeige des ALVs erstellt? Vermutlich Statisch.
Stimmt! Ja, CL_SALV_TABLE ist nicht editierbar
sry.
Zu deinem Problem:
Du könntest dir uU einen Klasse-zu-Struktur-Wrapper schreiben, der egal welche Klasse du anzeigen möchtest, die entsprechenden Informationen darstellt.
Mir schwebt da sowas vor indem du mit CL_ABAP_CLASSDESCR alle PUBLIC-Attribute der Klasse ausliest. Sind es normale Elemente (CL_ABAP_ELEMDESCR) fügst du zur LT_COMPONENT eine neue Felddefinition hinzu. Handelt es sich um Referenzen einer Klassen gehts du eine Rekursionsebene tiefer und wiederholst das ganze (Sprich alle PUBLIC-Attribute auslesen, ...) am Ende jeder Verarbeitungsebene fügst du noch ein Feld ein, welches die Klasse darstellt. Schließlich solltest du soetwas in der Art haben:
Die Befüllung der Tabelle muss dann ebenfalls Rekursiv erfolgen, wobei du wenn du jeweils 3 Instanzen hast die ineinander geschachtelt sind 27 Zeilen erhältst.
(3x3x3) Die fertige Methode kannst du dann überall einsetzten wo du Klassen in ALV abbilden willst.
Sobald im ALV was geändert wurde, musst du dann nur noch das entsprechende Attribut der jeweiligen Klasse ändern.
Public-Attribute desshalb, weil das Lesen/Schreiben möglich sein muss. Alternativ kannst du auch Getter/Setter verwenden, wobei du dich dann aber an Konventionen halten musst, was die Benennung der jeweiligen Methoden betrifft. (Alle zb. GET_* und SET_*)
lg ADT
Du hast so ne Art SDO gemacht, wo jede Klasse einer DB-Tabelle entspricht und jedes Objekt der Klassen einer jeweiligen Zeile.
Wie hast du die interne Struktur/Tabelle für die Anzeige des ALVs erstellt? Vermutlich Statisch.
Stimmt! Ja, CL_SALV_TABLE ist nicht editierbar
sry.Zu deinem Problem:
Du könntest dir uU einen Klasse-zu-Struktur-Wrapper schreiben, der egal welche Klasse du anzeigen möchtest, die entsprechenden Informationen darstellt.
Mir schwebt da sowas vor indem du mit CL_ABAP_CLASSDESCR alle PUBLIC-Attribute der Klasse ausliest. Sind es normale Elemente (CL_ABAP_ELEMDESCR) fügst du zur LT_COMPONENT eine neue Felddefinition hinzu. Handelt es sich um Referenzen einer Klassen gehts du eine Rekursionsebene tiefer und wiederholst das ganze (Sprich alle PUBLIC-Attribute auslesen, ...) am Ende jeder Verarbeitungsebene fügst du noch ein Feld ein, welches die Klasse darstellt. Schließlich solltest du soetwas in der Art haben:
Code: Alles auswählen.
Klasse1_Attribut1 type Char.
Klasse1_Attribut2 type Dec.
Klasse1_Attribut3 type Int.
Klasse1 type ref to Klasse1
Klasse2_Attribut1 type Char.
Klasse2_Attribut2 type Dec.
Klasse2_Attribut3 type Int.
Klasse2 type ref to Klasse2
Klasse3_Attribut1 type Char.
Klasse3_Attribut2 type Dec.
Klasse3_Attribut3 type Int.
Klasse3 type ref to Klasse3
(3x3x3) Die fertige Methode kannst du dann überall einsetzten wo du Klassen in ALV abbilden willst.
Sobald im ALV was geändert wurde, musst du dann nur noch das entsprechende Attribut der jeweiligen Klasse ändern.
Public-Attribute desshalb, weil das Lesen/Schreiben möglich sein muss. Alternativ kannst du auch Getter/Setter verwenden, wobei du dich dann aber an Konventionen halten musst, was die Benennung der jeweiligen Methoden betrifft. (Alle zb. GET_* und SET_*)
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hi!
Wenn jemand im Standard einen Report kennt, der ähnlich vor geht, immer her damit.
Gruß
In etwa, ja. Leider entspricht nicht exakt jede DB-Tabelle einer Klasse. Das einlesen der Daten in die entsprechende Klasse ist daher etwas umständlich. Zwar soll später im ALV ein Objekt eine Zeile darstellen, allerdings beinhaltet die Zeile noch weitere Attribute. Mal etwas anschaulicher: Ich hab ein Gertä, das verfügt über Parameterblöcke, die verfügen über Parameter. Zum Gerät lasse ich mir die Parameterblöcke im ALV anzeigen. Dort entspricht dann ein Parameterblock-Objekt einer Zeile, allerdings beinhaltet diese Zeile auch noch Spalten/Felder, die Auskunft zum aktuellen Parameter gibt. Beim Doppelklick auf einen Parameterblock öffnet sich unterhalb ein ALV mit den entsprechenden Parametern. Diese kann ich ändern. Aber auch hier entspricht nicht eine Zeile genau einem Objekt, denn in dieser Zeile des ALVs stehen auch noch Infos zum Parameterblock.a-dead-trousers hat geschrieben: Du hast so ne Art SDO gemacht, wo jede Klasse einer DB-Tabelle entspricht und jedes Objekt der Klassen einer jeweiligen Zeile.
Ja, ist eine statische Struktur für meine ALV.a-dead-trousers hat geschrieben:Wie hast du die interne Struktur/Tabelle für die Anzeige des ALVs erstellt? Vermutlich Statisch.
Kennst du im Standard einen Report, der sowas macht und den ich mir anschauen kann? Vermutlich nicht. =/a-dead-trousers hat geschrieben: Du könntest dir uU einen Klasse-zu-Struktur-Wrapper schreiben, der egal welche Klasse du anzeigen möchtest, die entsprechenden Informationen darstellt.
Wenn ich dich richtig verstanden habe, denke ich aber, dass das der richtige Weg sein könnte. Hoffe nur, dass ich das hinbekomme.a-dead-trousers hat geschrieben: Mir schwebt da sowas vor indem du mit CL_ABAP_CLASSDESCR alle PUBLIC-Attribute der Klasse ausliest. Sind es normale Elemente (CL_ABAP_ELEMDESCR) fügst du zur LT_COMPONENT eine neue Felddefinition hinzu. Handelt es sich um Referenzen einer Klassen gehts du eine Rekursionsebene tiefer und wiederholst das ganze (Sprich alle PUBLIC-Attribute auslesen, ...) am Ende jeder Verarbeitungsebene fügst du noch ein Feld ein, welches die Klasse darstellt.
Wenn jemand im Standard einen Report kennt, der ähnlich vor geht, immer her damit. Gruß
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
Die CL_ABAP_TYPEDESCR sind noch eine recht "neue" Technologie in SAP und werden auch nur in den vertiefenden Programmierkursen (z.b. BC351) behandelt.newbie007 hat geschrieben:Wenn ich dich richtig verstanden habe, denke ich aber, dass das der richtige Weg sein könnte. Hoffe nur, dass ich das hinbekomme.
Aber in letzter Zeit finde ich vermehrt auch in den Standardreports Stellen wo bereits die Klassen verwendet werden. Im Standard ist mir allerdings derzeit nichts bekannt wo ein solcher Klasse/Struktur-Wrapper verwendet wird. Das meiste hab ich mir hier in Eigenregie unter Zuhilfenahme der Unterlagen aus BC351 beigebracht.
Wenn du nicht weiterkommst, helfe ich dir gerne, aber auf dem Silbertablett kann ich die Lösung nicht servieren.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Jetzt muss ich diesen Thread leider nochmals aus der Versenkung holen...
Ich habe nun ein ALV, dessen Struktur unter anderem ein Feld mit einer Referenz auf eine
Klasse besitzt (welches ich nicht ausgebe). Nun stellt sich mir die Frage: Wie lösche eine Zeile und das
dazugehörige Objekt?
Der Anwender wählt eine Zeile und klickt löschen. Ich weiß dann, welche Zeile er löschen möchte
und komme darüber an mein Objekt, das ich löschen kann. Wenn ich nun aber dieses Objekt mittels
CLEAR lösche, dann ist es initial, aber immer noch vorhanden.
Wie muss ich dabei vorgehen?
Ich habe nun ein ALV, dessen Struktur unter anderem ein Feld mit einer Referenz auf eine
Klasse besitzt (welches ich nicht ausgebe). Nun stellt sich mir die Frage: Wie lösche eine Zeile und das
dazugehörige Objekt?
Der Anwender wählt eine Zeile und klickt löschen. Ich weiß dann, welche Zeile er löschen möchte
und komme darüber an mein Objekt, das ich löschen kann. Wenn ich nun aber dieses Objekt mittels
CLEAR lösche, dann ist es initial, aber immer noch vorhanden.
Wie muss ich dabei vorgehen?
Beitrag
von a-dead-trousers (Top Expert / 4399 / 223 /
1182
)
»
ABAP hat einen sog. Garbage-Collector ähnlich zu Java. Ein explizites "Löschen" eines Objektes ist nicht möglich!
Sobald alle Zeiger auf die Instanz (TYPE REF TO) gelöscht sind, wird dieer Umstand vom GC erkannt und die "verwaiste" Instanz wird aus dem Speicher entfernt.
Solltest du eine explizite Zerstörung benötigen, z.b. eine FTP-Verbindung ist offen, DB-Result-Zeiger ist nicht geschlossen, Controls müssen zerstört werden usw. dann musst du dafür eine Methode definieren die die erforderlichen "Zerstörungen" vornimmt (ähnlich der FREE-Methode bei den Controls).
Diese musst du dann logischerweise vor dem CLEAR aufrufen.
Man kann den GC auch händisch aufrufen
Das macht aber nur in den wenigsten Fällen wirklich Sinn.
lg ADT
Sobald alle Zeiger auf die Instanz (TYPE REF TO) gelöscht sind, wird dieer Umstand vom GC erkannt und die "verwaiste" Instanz wird aus dem Speicher entfernt.
Solltest du eine explizite Zerstörung benötigen, z.b. eine FTP-Verbindung ist offen, DB-Result-Zeiger ist nicht geschlossen, Controls müssen zerstört werden usw. dann musst du dafür eine Methode definieren die die erforderlichen "Zerstörungen" vornimmt (ähnlich der FREE-Methode bei den Controls).
Diese musst du dann logischerweise vor dem CLEAR aufrufen.
Man kann den GC auch händisch aufrufen
Code: Alles auswählen.
system-call OBJMGR perform GARBAGE COLLECTION.lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Jetzt frage ich mich nur, ob das in meinem Fall überhaupt notwendig ist.a-dead-trousers hat geschrieben:...dann musst du dafür eine Methode definieren die die erforderlichen "Zerstörungen" vornimmt
Ich habe mir Datenbestände aus der Datenbank geladen und daraus meine Objekte erzeugt. Eine Zeile im ALV entspricht einem Objekt, wie ja im Thread bereits erwähnt. Zusätzlich habe ich den Zeilen im ALV die entsprechende Objektreferenz zugewiesen um über das ALV an das entsprechende Objekt zu gelangen.
Wenn ich nun aber die Zeile und somit auch das entsprechende Objekt löschen möchte, ist es dann auch tatsächlich entfernt? Als ich am SAP-System saß und das Löschen des Objekts programmiert hatte, war die ursprüngliche Objektreferenz noch in einer internen Tabelle vorhanden (und nicht initial), im ALV war die Objektreferenz jedoch auf INITIAL gesetzt?! Den Garbage Collector habe ich nicht händisch aufgerufen...
Wie programmiert man es "richtig", dass wenn ich mir das Objekt über das ALV hole und lösche, es aus dem gesamten Speicher gelöscht wird.
Grüße
Beitrag
von black_adept (Top Expert / 4098 / 128 /
941
)
»
Hallo newbie,
du musst "nur" alle Referenzen auf das zu löschende Objekt entfernen und danach das Objekt selber. Damit ist es dann vogelfrei und der Garbagecollector wird es abräumen sobald er der Meinung ist, dass es mal wieder Zeit wird für Ordnung zu sorgen.
Ob es bis dahin noch im Speicher residiert kann dir eigentlich egal sein. Da man nicht mehr darauf zugreifen kann ist es de facto schon gelöscht.
Vergleich es doch mit lokalen Variablen von Unterroutinen auf dem Stack. Diese werden beim Aufruf der Unterroutine angelegt und beim Verlassen wird der Stackpointer so verschoben, dass diese lokalen Variablen nicht mehr angesprochen werden können. Memorytechnisch könnten die durchaus noch vorhanden sein - aber sie sind nicht mehr ansprechbar ( offiziell zumindest ) und somit quasi gelöscht.
du musst "nur" alle Referenzen auf das zu löschende Objekt entfernen und danach das Objekt selber. Damit ist es dann vogelfrei und der Garbagecollector wird es abräumen sobald er der Meinung ist, dass es mal wieder Zeit wird für Ordnung zu sorgen.
Ob es bis dahin noch im Speicher residiert kann dir eigentlich egal sein. Da man nicht mehr darauf zugreifen kann ist es de facto schon gelöscht.
Vergleich es doch mit lokalen Variablen von Unterroutinen auf dem Stack. Diese werden beim Aufruf der Unterroutine angelegt und beim Verlassen wird der Stackpointer so verschoben, dass diese lokalen Variablen nicht mehr angesprochen werden können. Memorytechnisch könnten die durchaus noch vorhanden sein - aber sie sind nicht mehr ansprechbar ( offiziell zumindest ) und somit quasi gelöscht.
Hi!
Ich hole mir über das ALV eine Objektreferenz und muss dann ja im Grunde mein Programm nach Referenzen durchsuchen, die dem des ALVs entsprechen, oder? Und erst dann kann ich alle Referenzen löschen?
Also muss ich mir erst alle Referenzen holen, die auf das Objekt zeigen und diese dann mittels CLEAR löschen? Das ist in meinem Fall irgendwie total umständlich wie ich finde....black_adept hat geschrieben:du musst "nur" alle Referenzen auf das zu löschende Objekt entfernen und danach das Objekt selber. Damit ist es dann vogelfrei und der Garbagecollector wird es abräumen sobald er der Meinung ist, dass es mal wieder Zeit wird für Ordnung zu sorgen.
Ich hole mir über das ALV eine Objektreferenz und muss dann ja im Grunde mein Programm nach Referenzen durchsuchen, die dem des ALVs entsprechen, oder? Und erst dann kann ich alle Referenzen löschen?
Vergleichbare Themen
3
Antw.
Antw.
15211
Views
Views
1
Antw.
Antw.
2723
Views
Views
Dialogsteuerung Liste->Dynpro->Liste sy-ucomm
von cut1 » 08.12.2006 14:28 • Verfasst in Dialogprogrammierung
von cut1 » 08.12.2006 14:28 • Verfasst in Dialogprogrammierung
3
Antw.
Antw.
3985
Views
Views
Screen->Liste->Screen und dann wieder Liste???
von dimes » 19.07.2007 15:19 • Verfasst in Dialogprogrammierung
von dimes » 19.07.2007 15:19 • Verfasst in Dialogprogrammierung
0
Antw.
Antw.
1245
Views
Views
1
Antw.
Antw.
1769
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.