gelöst Lokale Klasse in zwei Dynpros


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

gelöst Lokale Klasse in zwei Dynpros

Beitragvon Aba » 15.02.2018, 16:43

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
Aba
ForumUser
 
Beiträge: 24
Registriert: 31.01.2018, 09:45
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Lokale Klasse in zwei Dynpros

Beitragvon black_adept » 15.02.2018, 17:50

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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon Aba » 16.02.2018, 09:28

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?
Aba
ForumUser
 
Beiträge: 24
Registriert: 31.01.2018, 09:45
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon black_adept » 16.02.2018, 09:47

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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
Aba
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon Aba » 16.02.2018, 11:27

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:
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.
 

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.
Aba
ForumUser
 
Beiträge: 24
Registriert: 31.01.2018, 09:45
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon a-dead-trousers » 16.02.2018, 12:12

Nein.
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.07
Basis: 7.40
a-dead-trousers
Top Expert
 
Beiträge: 3090
Registriert: 07.02.2011, 13:40
Dank erhalten: 762 mal
Ich bin: Entwickler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon Aba » 16.02.2018, 12:23

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?
Aba
ForumUser
 
Beiträge: 24
Registriert: 31.01.2018, 09:45
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon black_adept » 16.02.2018, 12:42

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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon black_adept » 16.02.2018, 12:44

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.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 3101
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 526 mal
Ich bin: Freiberufler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon Aba » 16.02.2018, 12:52

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.

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.
Aba
ForumUser
 
Beiträge: 24
Registriert: 31.01.2018, 09:45
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Lokale Klasse in zwei Dynpros

Beitragvon gtoXX » 25.02.2018, 18:45

Aba hat geschrieben:
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.

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.

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.
gtoXX
Specialist
 
Beiträge: 111
Registriert: 27.03.2017, 12:14
Dank erhalten: 14 mal
Ich bin: Entwickler/in


Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
500 Internal Server Error
vor 4 Stunden von zzcpak 1 Antw.
Dokumentinformationen lesen vom DVS
vor 6 Stunden von Tron 4 Antw.
Tabs innerhalb von Tabs
vor 7 Stunden von ewx 4 Antw.
Fakturierungsplan in Kontrakten ändern
vor 3 Stunden von DeathAndPain 1 Antw.
Scope items
vor 4 Tagen von SAP_ENTWICKLER 0 Antw.

  Ähnliche Beiträge beta
Lokale Tabellen.
26.06.2008, 10:14 von Dzhan 7 Antw.
gelöst ENDFORM - werden lokale Daten verworfen?
01.02.2018, 15:58 von lausek 1 Antw.
Lokale Kopie eines SAP-Programms nicht ausführbar
11.06.2008, 18:03 von muelly 6 Antw.
Dynpros
26.05.2004, 18:05 von babap 2 Antw.
Zwei Fragen
03.09.2004, 12:07 von Hermann 3 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]