Lokale Klasse in zwei Dynpros
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo zusammen,
folgendes Szenario: Ich habe in einem Programm zwei Dynpros, die jeweils ein ALV enthalten. Das erste ALV hat jedoch eine andere Struktur als das zweite ALV, sprich sie geben unterschiedliche Werte aus. Ich habe eine lokale Klasse für die Event-Behandlung des ALVs implementiert, in der bspw. auf das Löschen, Ändern von Zeilen reagiert werden soll. Mein Problem ist, dass wenn ich die Event-Handler benutze, diese nur für eines der ALVs funktionieren, da ich in den Behandlungsmethoden ja Datentypen angeben muss, wie bspw. den Tabellentyp der Ausgabetabelle des ALVs.
Hat jemand eine Idee, wie ich die lokale Klasse für beide ALVs nutzen kann?
Danke
Aba
folgendes Szenario: Ich habe in einem Programm zwei Dynpros, die jeweils ein ALV enthalten. Das erste ALV hat jedoch eine andere Struktur als das zweite ALV, sprich sie geben unterschiedliche Werte aus. Ich habe eine lokale Klasse für die Event-Behandlung des ALVs implementiert, in der bspw. auf das Löschen, Ändern von Zeilen reagiert werden soll. Mein Problem ist, dass wenn ich die Event-Handler benutze, diese nur für eines der ALVs funktionieren, da ich in den Behandlungsmethoden ja Datentypen angeben muss, wie bspw. den Tabellentyp der Ausgabetabelle des ALVs.
Hat jemand eine Idee, wie ich die lokale Klasse für beide ALVs nutzen kann?
Danke
Aba
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Entweder 2 Eventhandler bauen und je einen pro Grid registrieren oder einen Eventhandler nehmen und dann über "Sender" bestimmen welcher Grid gerade den Event gefeuert hat.
Das mit dem einen Eventhandler und dann über die Sender hatte ich auch vor. Wie aber mache ich das in der Eventhandlerklasse dann die Datentypen automatisch entsprechend dem ALV Datentyp erstellt werden? Möchte quasi folgendes haben:
ALV 1 gibt Daten der Tabelle z_tab1 mit Datentyp mara im Dynpro 100 aus.
ALV 2 gibt Daten der Tabelle z_tab2 mit Datentyp marc im Dynpro 200 aus.
Beide Dynpros sollen die gleichen Funktionen, wie eine individuelle Toolbar, das Reagieren auf Button-, Zeilenklicks und weitere haben.
Die lokale Klasse lcl_event behandelt alle diese Funktionen. Bei den Funktionen (Bsp. Zeilenklick) ist das Angeben des Datentyps der ALV Ausgabetabelle notwendig, da darüber dann bspw. die geänderten Daten bestimmt werden.
Ist eine unterschiedliche Typdefinition abhängig vom aufrufenden Sender möglich oder muss ich in der lokalen Klasse, dann immer auf die Dynpronummer abfragen und die Codes dann quasi zweimal jedoch basierend auf unterschiedlichen Definitionen implementieren?
ALV 1 gibt Daten der Tabelle z_tab1 mit Datentyp mara im Dynpro 100 aus.
ALV 2 gibt Daten der Tabelle z_tab2 mit Datentyp marc im Dynpro 200 aus.
Beide Dynpros sollen die gleichen Funktionen, wie eine individuelle Toolbar, das Reagieren auf Button-, Zeilenklicks und weitere haben.
Die lokale Klasse lcl_event behandelt alle diese Funktionen. Bei den Funktionen (Bsp. Zeilenklick) ist das Angeben des Datentyps der ALV Ausgabetabelle notwendig, da darüber dann bspw. die geänderten Daten bestimmt werden.
Ist eine unterschiedliche Typdefinition abhängig vom aufrufenden Sender möglich oder muss ich in der lokalen Klasse, dann immer auf die Dynpronummer abfragen und die Codes dann quasi zweimal jedoch basierend auf unterschiedlichen Definitionen implementieren?
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Du willst also dynamisch vorgehen. Hier mal ein möglicher Ablauf
Code: Alles auswählen.
FIELD-SYMBOLS:
<lt_table> TYPE standard table,
<ls_row> TYPE any ,
<lv_field> TYPE any.
CASE sender.
WHEN grid1. ASSIGN Datentabelle 1 to <lt_table>
WHEN grid2. ASSIGN Datentabelle 2 to <lt_table>.
when others. ASSERT 1 = 0.
ENDCASE.
READ TABLE <lt_table> assigning <ls_row> index row.
CHECK sy-subrc = 0.
ASSIGN component column OF STRUCTURE <ls_row> to <lv_field>.
CHECK sy-subrc = 0.
CASE column.
WHEN 'MATNR'.
WHEN 'DISPO'.
WHEN ...
endcase.Das sieht schon mal super aus. Gibt es diese dynamische Möglichkeit auch für normale Tabellen bzw Strukturen und nicht nur für Field-Symbols?
Ungefähr so:
Wenn ich das so probiere, kommt eine Fehlermeldung bei der zweiten Data Definition, dass lt_outtab ja schon definiert ist, was natürlich auch stimmt.
Ungefähr so:
Code: Alles auswählen.
case sender.
when grid1.
data: lt_outtab type table of mara.
when grid2.
data: lt_outtab type table of marc.
endcase.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Nein.
Dann müsstest du auch den ganzen weiteren Code (statisch) doppelt schreiben.
Dann müsstest du auch den ganzen weiteren Code (statisch) doppelt schreiben.
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
Sprich es macht wahrscheinlich doch am meisten Sinn zwei lokale Eventhandler Klassen zu implementieren, damit ich nicht immer auf die Dynpronummer und so abfragen muss oder wie seht ihr das?
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Das kommt ganz darauf an was du im Eventhandler machen willst.
Wenn du - egal auf welchem Grid du dich befindest - z.b. in den Materialstamm (MM02) navigieren willst brauchst du keine 2 Handler sondern kannst fast den Ansatz übernehmen. Aber wenn sich die Art der Eventbehandlung von Grid zu Grid unterscheidet was jeweils möglich ist macht es viel mehr Sinn das Ganze statisch (und damit auch deutlich leichter lesbar ) zu gestalten und dann halt 2 Eventhandler zu definieren.
1 Handler für mehrere Grids eignet sich halt nur dann, wenn diese Grids sich tatsächlich gleich verhalten sollen.
Wenn du - egal auf welchem Grid du dich befindest - z.b. in den Materialstamm (MM02) navigieren willst brauchst du keine 2 Handler sondern kannst fast den Ansatz übernehmen. Aber wenn sich die Art der Eventbehandlung von Grid zu Grid unterscheidet was jeweils möglich ist macht es viel mehr Sinn das Ganze statisch (und damit auch deutlich leichter lesbar ) zu gestalten und dann halt 2 Eventhandler zu definieren.
1 Handler für mehrere Grids eignet sich halt nur dann, wenn diese Grids sich tatsächlich gleich verhalten sollen.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Ach ja - ich verstehe nicht warum du immer auf die Dynpronummer abfragen willst. Frage doch direkt ab, welcher Grid den Event gefeuert hat über den SENDER-Parameter des Events, falls die Grids global definiert sind.
Da hast du Recht, das stimmt.Ach ja - ich verstehe nicht warum du immer auf die Dynpronummer abfragen willst. Frage doch direkt ab, welcher Grid den Event gefeuert hat über den SENDER-Parameter des Events, falls die Grids global definiert sind.
Die zwei ALVs sollen zur Pflege von Tabellendaten genutzt werden. ALV 1 soll quasi Kopfdaten anzeigen und bei Auswahl von Kopfdaten soll in die Detaildaten in ALV 2 gesprungen werden. Deswegen müssen die auch beide die Funktionen des Updates, Inserts und so bei den DB haben.
Was mir gerade zu der dynamischen Fieldsymbolzuweisung noch aufgefallen ist, dass man dann gar nicht auf einzelne Komponenten zugreifen kann im Code, da dann die Fehlermeldung "<feldsymbol>-spalte unbekannt" kommt.
ich glaube ich werde einfach zwei eigene machen. Erscheint mir jetzt doch gerade einfacher.
Richtig, auf Komponenten kann nicht zugegriffen werden, da es sich um untypisierte Feldsymbole handelt. Dann müsstest Du mit CREATE DATA arbeiten.Aba hat geschrieben:Da hast du Recht, das stimmt.Ach ja - ich verstehe nicht warum du immer auf die Dynpronummer abfragen willst. Frage doch direkt ab, welcher Grid den Event gefeuert hat über den SENDER-Parameter des Events, falls die Grids global definiert sind.
Die zwei ALVs sollen zur Pflege von Tabellendaten genutzt werden. ALV 1 soll quasi Kopfdaten anzeigen und bei Auswahl von Kopfdaten soll in die Detaildaten in ALV 2 gesprungen werden. Deswegen müssen die auch beide die Funktionen des Updates, Inserts und so bei den DB haben.
Was mir gerade zu der dynamischen Fieldsymbolzuweisung noch aufgefallen ist, dass man dann gar nicht auf einzelne Komponenten zugreifen kann im Code, da dann die Fehlermeldung "<feldsymbol>-spalte unbekannt" kommt.
ich glaube ich werde einfach zwei eigene machen. Erscheint mir jetzt doch gerade einfacher.
Die Funktionen des Updates, Inserts kannst Du auch dynamisch angeben. Dafür braucht es keine 2 Eventhandler. Wozu du dann allerdings einzeln auf Komponenten zugreifen musst ,erschliesst sich hier nicht. Du updatest ja immer am performantesten von den internen Tabellen direkt und nicht jede Spalte einzeln.
"Code lügt nicht ^^"
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2690
Views
Views
Lokale Klasse autom. in globale Klasse ändern
von JohnLocklay » 09.01.2019 09:10 • Verfasst in ABAP Objects®
von JohnLocklay » 09.01.2019 09:10 • Verfasst in ABAP Objects®
3
Antw.
Antw.
1219
Views
Views
lokale klasse in include verwenden
von L0w-RiDer » 02.02.2024 18:22 • Verfasst in ABAP® für Anfänger
von L0w-RiDer » 02.02.2024 18:22 • Verfasst in ABAP® für Anfänger
12
Antw.
Antw.
7988
Views
Views
2
Antw.
Antw.
2215
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.