Unterschied bei ALV-Klassen
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Hallo,
bisher habe ich immer den REUSE-Baustein oder die Klasse CL_GUI_ALV_GRID verwendet. Der Nachteil von der Klasse ist, dass man einen extra Dynpro anlegen muss. Jetzt habe ich die Klasse CL_SALV_TABLE entdeckt, für die man nicht extra ein Dynpro braucht. Meine Frage ist, welche die bessere Lösung oder welche mehr Vorteile hat? Welche sollte man eher verwenden und warum?
bisher habe ich immer den REUSE-Baustein oder die Klasse CL_GUI_ALV_GRID verwendet. Der Nachteil von der Klasse ist, dass man einen extra Dynpro anlegen muss. Jetzt habe ich die Klasse CL_SALV_TABLE entdeckt, für die man nicht extra ein Dynpro braucht. Meine Frage ist, welche die bessere Lösung oder welche mehr Vorteile hat? Welche sollte man eher verwenden und warum?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Deine Aussage "man müsse immer ein Dynpro anlegen" stimmt nicht!:
http://www.tricktresor.de/content/index ... 25&aID=561
Ein toller Vorteil des SALV-Modells ist z.B. dass du jede x-beliebige interne tabelle einfach an den SALV übergeben kannst und sie wird angezeigt, ohne dass man eine Struktur vorgeben oder einen Feldkatalog definieren müsste.
that's it...
Nachteilig finde ich, dass durch das strikte OO-Konzept viele Dinge umständlicher zu bewerkstelligen sind. Da muss man sich dann das Objekt zu irgendwas holen, wo man aus einer tabelle dieses objektes wieder ein entsprechendes objekt erzeugen muss auf dess methoden man dann zugreift um eine eigenschaft zu ändern.
http://www.tricktresor.de/content/index ... 25&aID=561
Ein toller Vorteil des SALV-Modells ist z.B. dass du jede x-beliebige interne tabelle einfach an den SALV übergeben kannst und sie wird angezeigt, ohne dass man eine Struktur vorgeben oder einen Feldkatalog definieren müsste.
Code: Alles auswählen.
CALL METHOD cl_salv_table=>factory
IMPORTING
r_salv_table = lr_salv
CHANGING
t_table = lt_data.
lr_salv->display( ).
Nachteilig finde ich, dass durch das strikte OO-Konzept viele Dinge umständlicher zu bewerkstelligen sind. Da muss man sich dann das Objekt zu irgendwas holen, wo man aus einer tabelle dieses objektes wieder ein entsprechendes objekt erzeugen muss auf dess methoden man dann zugreift um eine eigenschaft zu ändern.
SALV kann nicht zum editieren genutzt werden (ok mit Tricks geht das dann doch) und man hat weniger Arbeit mit dem Fieldcat da dieser per RTTS automatisch ermittelt wird und auch die Bufferung des Fcat ist besser gelöst.zer0 hat geschrieben:Jetzt habe ich die Klasse CL_SALV_TABLE entdeckt, für die man nicht extra ein Dynpro braucht. Meine Frage ist, welche die bessere Lösung oder welche mehr Vorteile hat? Welche sollte man eher verwenden und warum?
Am Ende gehen alle ALV-Aufrufe auf den OO-ALV zurück, ist also nur der Aufruf, der etwas anders ist.
Ich nehm immer den, der auf meine Anforderungen am besten zugeschnitten ist.
Gruß Hendrik
In dem von dir genannten Beispiel muss trotzdem noch ein leerer Dynpro angelegt werden! Durch den Trick kommt man nur um den CustomContainer herum.ewx hat geschrieben:Deine Aussage "man müsse immer ein Dynpro anlegen" stimmt nicht!:
http://www.tricktresor.de/content/index ... 25&aID=561
Sorry! Stimmt! 
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Einen Screen wo man den ALV anzeigt braucht man immer! Aber wie ewx schon gesagt hat muss man den nicht unbedingt anlegen.
Wenn ich faul bin benutze ich den SALV, nehme als Screen den CL_GUI_CONTAINER=>SCREEN0 und erzeuge meinen Screen nur implizit durch ein "WRITE '.'."
Wenn ich faul bin benutze ich den SALV, nehme als Screen den CL_GUI_CONTAINER=>SCREEN0 und erzeuge meinen Screen nur implizit durch ein "WRITE '.'."
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Meine ganz persönlichen Vorlieben:zer0 hat geschrieben: Meine Frage ist, welche die bessere Lösung oder welche mehr Vorteile hat? Welche sollte man eher verwenden und warum?
1.) REUSE - Bausteine
Da ich in meinem Hauptprojekt zig Vorlagen auf dieser Basis habe nehme ich den gerne wg. Copy&Paste. Der hat auch den Vorteil, dass er im Hintergrund lauffähig ist und dann automatisch auf den LIST-Display umschaltet und somit einen brauchbaren Spool erzeugen kann. Außerdem muss ich tatsächlich keinen eigenen Dynpro anlegen, was das "Mitnehmen" zu anderen Projekten erleichtert wenn ich nicht SAPLINK installiert habe. Letztlich ist dies auch die "älteste" Technik, da extrem stark mit dem uralten REUSE_ALV_LIST_DISPLAY verwandt - der kann auch von Personen gewartet werden, die (noch) nicht so stark in den neueren Techniken bewandert sind.
2.) SALV
Ich bin momentan immer mehr am Umstellen auf diese Technik. Hat etwas gedauert bis ich damit klar kam - aber je mehr ich damit arbeite desto mehr weiß ich es zu schätzen. Im Großen und Ganzen entspricht das was man damit machen kann dem REUSE-Baustein - das Einzige wo ich momentan noch nicht genug geschaut habe und was mich stört ist dass ich beim EVENT-Handling keine Referenz auf meinen SENDER-Alv bekomme.
Schön ist hier auf jeden Fall der unkomplizierte Feldkatalogaufbau wenn man keine eigenen FuBa/Methoden dafür in petto hat.
Nicht so schön ist das umständliche Festlegen einer Spalte auf einen fest definierten Spaltenbeschrifter - aber wahrscheinlich gibt es dafür auch einen Trick statt alle 3 Text auf denselben String zu setzen. Das geht beim ReUSE-Baustein besser.
3.) cl_gui_alv_grid
Nehme ich meistens wenn ich dann doch auf "echte" Dynproprogrammierung zurückgreifen muss. Obwohl der SALV als mein neuer Freund da auch immer öfter mal den Vorzug bekommt. Dies ist auch der Grid, der am Besten mit Usereingaben umgehen kann (und ja - der REUSE-Baustein kann das auch ) und die meisten Möglichkeiten bietet. Aber ich bin kein allzu großer Freund von eingabebereiten Grids, so dass ich das i.A. versuche zu vermeiden und auf die gute alte DYNPRO-Eingabe zurückgreife. Zur Not auch mit Table-Controls. Grund hierbei ist, dass sich im Laufe eines (größeren) Projekts doch mal hier und da der Wunsch aufkommt irgendwelche Prozesse zu automatisieren. Und das geht dann mit dem guten alten BI oder CT recht einfach, wenn man keine Enjoy-Controls verwendet. Sieht aber leider dann so aus wie oft im SAP - recht altbacken.
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Das kann auch der SALV sowie der CL_GUI_ALV_GRIDblack_adept hat geschrieben:1.) REUSE - Bausteine
... Der hat auch den Vorteil, dass er im Hintergrund lauffähig ist und dann automatisch auf den LIST-Display umschaltet und somit einen brauchbaren Spool erzeugen kann ...
Meinst du direkt auf die Instanz vom verwendeten CL_GUI_ALV_GRID, oder die Instanz des SALV? Normalerweise wird die Instanz welche den Event ausgelöst hat ja über den SENDER (einfach in der Parameterliste so reinschreiben) zurückübergeben. Theoretisch, wenn man mehrere Instanzen verwendet müsste man sich halt eine Art "Identifikation" einfallen lassen. z.B. Ist die Event-Instanz des SALV gleich dem Sender des Events, dann ist der Auslöser des Events in Wahrheit der gesuchte SALV.black_adept hat geschrieben:2.) SALV
...das Einzige wo ich momentan noch nicht genug geschaut habe und was mich stört ist dass ich beim EVENT-Handling keine Referenz auf meinen SENDER-Alv bekomme...
Amen!black_adept hat geschrieben:3.) cl_gui_alv_grid
... Aber ich bin kein allzu großer Freund von eingabebereiten Grids, so dass ich das i.A. versuche zu vermeiden und auf die gute alte DYNPRO-Eingabe zurückgreife. Zur Not auch mit Table-Controls. Grund hierbei ist, dass sich im Laufe eines (größeren) Projekts doch mal hier und da der Wunsch aufkommt irgendwelche Prozesse zu automatisieren. Und das geht dann mit dem guten alten BI oder CT recht einfach, wenn man keine Enjoy-Controls verwendet...
Finde ich jetzt nicht. Man kann auch mit den normalen Dynpros recht ansprechende Bildschirmmasken zaubern.black_adept hat geschrieben:...Sieht aber leider dann so aus wie oft im SAP - recht altbacken...
Stichwort: Icons
Fast überall kann man als Text folgende Syntax anwenden
Code: Alles auswählen.
'@01\QInfo@ TextAußerdem kann man nur mit Dynpros in den Tabellen einen Radiobutton 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
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hmm gerade darauf gestoßen:
Nachteil des CL_SALV_TABLE: Er kann (zumindest nicht ohne Trickserei) kein Drag&Drop
Nachteil des CL_SALV_TABLE: Er kann (zumindest nicht ohne Trickserei) kein Drag&Drop
Um das Thema nochmal herauszugraben: Kann mir jemand sagen, wie ich beim CL_SALV_TABLE die Zeilenauswahl aktivieren kann? Ich möchte ganz links diese Quadrate haben, wo mit ich dann mehrere Zeilen markieren kann?
Ich hoffe meine Antwort passt zu CL_SALV_TABLE.
In dem Paket SLIS gibt es einige Beispiele. Vergleiche mal die Programme BCALV_TEST_GRID und z.B. BCALV_TEST_GRID_EDIT. Der erste hat keine Selektionsspalte.
Oder such allgemein nach set_selection_mode.
Wenn du mit LVC_S_LAYO arbeitest, dann ist es das Feld SEL_MODE.
In dem Paket SLIS gibt es einige Beispiele. Vergleiche mal die Programme BCALV_TEST_GRID und z.B. BCALV_TEST_GRID_EDIT. Der erste hat keine Selektionsspalte.
Oder such allgemein nach set_selection_mode.
Wenn du mit LVC_S_LAYO arbeitest, dann ist es das Feld SEL_MODE.
Gruß
bliss
.|.. .. ...| . .|.. ||| |. ||. .| |. |.. .||. .|. ||| ... .||. . .|.
Ich bin Anfänger und meine Tipps sind mit Vorsicht zu genießen.
bliss
.|.. .. ...| . .|.. ||| |. ||. .| |. |.. .||. .|. ||| ... .||. . .|.
Ich bin Anfänger und meine Tipps sind mit Vorsicht zu genießen.
Beitrag
von black_adept (Top Expert / 4116 / 129 /
951
)
»
Hallo zer0,
Code: Alles auswählen.
* Row Selection
lo_selections = go_salv->get_selections( ).
lo_selections->set_selection_mode( cl_salv_selections=>row_column ).
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Ich frag das mal hier, weil das genau reinpasst:
Wo mache ich den Fehler? Wie kann ich aus dieser Angabe Rückschlüsse darauf ziehen, welches SALV-Grid das Event ausgelöst hat und wie greife ich auf Attribute dieses Objektes zu?
Ich habe gerade genau dieses Problem, ich habe mehrere SALVs und kriege über den Parameter "sender" meines Eventhandlers keinen Hinweis darauf, welche Instanz meines Grid das Event ausgelöst hat, sondern eine Instanz von CL_SALV_EVENTS_TABLE. Und so sieht das dann im Debugger aus (Parameter SENDER in meiner Eventhandlermethode):a-dead-trousers hat geschrieben:Meinst du direkt auf die Instanz vom verwendeten CL_GUI_ALV_GRID, oder die Instanz des SALV? Normalerweise wird die Instanz welche den Event ausgelöst hat ja über den SENDER (einfach in der Parameterliste so reinschreiben) zurückübergeben. Theoretisch, wenn man mehrere Instanzen verwendet müsste man sich halt eine Art "Identifikation" einfallen lassen. z.B. Ist die Event-Instanz des SALV gleich dem Sender des Events, dann ist der Auslöser des Events in Wahrheit der gesuchte SALV.black_adept hat geschrieben:2.) SALV
...das Einzige wo ich momentan noch nicht genug geschaut habe und was mich stört ist dass ich beim EVENT-Handling keine Referenz auf meinen SENDER-Alv bekomme...
Wo mache ich den Fehler? Wie kann ich aus dieser Angabe Rückschlüsse darauf ziehen, welches SALV-Grid das Event ausgelöst hat und wie greife ich auf Attribute dieses Objektes zu?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4419 / 224 /
1189
)
»
Vergleiche deinen SENDER mal mit den Rückgaben der Methode GET_EVENT aller deiner SALV-Grids.
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
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Was soll ich da vergleichen? Wie im Bild zu sehen ist, steht ja nix Spezifisches drin, was man vergleichen könnte....
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Vergleichbare Themen
8
Antw.
Antw.
9649
Views
Views
Architektur von Abap-Klassen (Klassen Attribute)
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
von snooze » 12.04.2005 12:56 • Verfasst in ABAP Objects®
20
Antw.
Antw.
3797
Views
Views
Globale Klassen oder Lokale Klassen
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
von ZF_SAPler » 29.11.2022 13:47 • Verfasst in ABAP® für Anfänger
9
Antw.
Antw.
5927
Views
Views
1
Antw.
Antw.
3169
Views
Views
0
Antw.
Antw.
4868
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.