Handler- und ALV-Problem
9 Beiträge
•
Seite 1 von 1
9 Beiträge
Seite 1 von 1
Moin!
Ich hab unten mal paar Codeschnipsel dargestellt, die hoffentlich dabei helfen werden, mein (Anfänger-)Problem zu lösen.
Es ist so, dass ich eine lokale Klasse habe, die sich um die Events kümmert und eine, die sich um die Bildschirmausgabe kümmert (Objekt von cl_gui_alv_grid erzeugen, Feldkatalog aufbauen etc.). Nun ist es so, dass mein Report zwei ALV-Listen besitzt. Die erste wird beim initialisieren erstellt (statische Methode init_screen).
Mein Problem ist nun, dass ich nicht (so richtig) weiß, wie ich meine zweite ALV-Liste erstellen soll. Die soll erst beim Doppelklick auf die erste Liste erstellt werden.
Am einfachsten wäre natürlich eine weitere statische Methode zu verwenden, aber das ist ja eigentlich nicht der Sinn von Objektorientierung?!
Daher wollte ich euch fragen, wie man es besser machen kann?
Vielen Dank im Voraus!
Ich hab unten mal paar Codeschnipsel dargestellt, die hoffentlich dabei helfen werden, mein (Anfänger-)Problem zu lösen.
Es ist so, dass ich eine lokale Klasse habe, die sich um die Events kümmert und eine, die sich um die Bildschirmausgabe kümmert (Objekt von cl_gui_alv_grid erzeugen, Feldkatalog aufbauen etc.). Nun ist es so, dass mein Report zwei ALV-Listen besitzt. Die erste wird beim initialisieren erstellt (statische Methode init_screen).
Mein Problem ist nun, dass ich nicht (so richtig) weiß, wie ich meine zweite ALV-Liste erstellen soll. Die soll erst beim Doppelklick auf die erste Liste erstellt werden.
Am einfachsten wäre natürlich eine weitere statische Methode zu verwenden, aber das ist ja eigentlich nicht der Sinn von Objektorientierung?!
Daher wollte ich euch fragen, wie man es besser machen kann?
Code: Alles auswählen.
CLASS lcl_screen DEFINITION.
PUBLIC SECTION.
CLASS-METHODS: init_screen.
METHODS constructor.
PRIVATE SECTION.
METHODS: get_fieldcat,
set_settings IMPORTING im_alv_grid TYPE REF TO cl_gui_alv_grid.
ENDCLASS.
CLASS lcl_screen IMPLEMENTATION.
METHOD init_screen.
DATA ref_screen TYPE REF TO lcl_screen.
CREATE OBJECT ref_screen.
ENDMETHOD.
ENDCLASS.
CLASS lcl_handler DEFINITION.
PUBLIC SECTION.
METHODS: on_doubleclick
FOR EVENT double_click OF cl_gui_alv_grid
IMPORTING e_row.
ENDCLASS.
CLASS lcl_handler IMPLEMENTATION.
* Doppelklick behandeln
METHOD on_doubleclick.
"wie kann ich jetzt hier das zweite ALV erzeugen??
ENDMETHOD.
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 / 4395 / 223 /
1182
)
»
hi!
Da gibts einige Möglichkeiten:
- Ein neues Dynpro mit Container für das andere ALV aufrufen. (CALL SCREEN)
- Einen DialogBox-Container erstellen und darin anzeigen. (CL_GUI_DIALOGBOX_CONTAINER)
- Einen Docking-Container erstellen und darin anzeigen. (CL_GUI_DOCKING_CONTAINER)
- Das zweite ALV (sofern nicht editierbar) mittels SALV darstellen (würde CALL SCREEN machen wobei du aber kein weiteres Dynpro benötigst). (CL_SALV_TABLE=>FACTORY)
lg
ADT
P.S.: an Wochenenden arbeite ich nicht
Da gibts einige Möglichkeiten:
- Ein neues Dynpro mit Container für das andere ALV aufrufen. (CALL SCREEN)
- Einen DialogBox-Container erstellen und darin anzeigen. (CL_GUI_DIALOGBOX_CONTAINER)
- Einen Docking-Container erstellen und darin anzeigen. (CL_GUI_DOCKING_CONTAINER)
- Das zweite ALV (sofern nicht editierbar) mittels SALV darstellen (würde CALL SCREEN machen wobei du aber kein weiteres Dynpro benötigst). (CL_SALV_TABLE=>FACTORY)
lg
ADT
P.S.: an Wochenenden arbeite ich nicht
newbie007 hat geschrieben:Kann mir niemand helfen? Oder liegt es an der Frage? Ist die Fragestellung oder Ausgangssituation nicht ganz klar?
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
Was ist das denn für eine Arbeitsmoral.a-dead-trousers hat geschrieben: P.S.: an Wochenenden arbeite ich nicht
Vielen Dank schon mal für deinen Post. Leider bin ich noch nicht dazu gekommen, eines davon zu testen. Wird dann wohl erst morgen was.
Allerdings habe ich noch kurz gegoogled. Es scheint, dass CL_GUI_DIALOGBOX_CONTAINER bei modalen Fenstern Anwendung findet, das ist bei mir nicht gewünscht. Und mittels SALV kann ichs leider auch nicht darstellen, da es editierbar sein soll.
Schränkt das meine Auswahl dann noch weiter ein? Was würdest du unter diesen Voraussetzungen empfehlen, bzw. was kann überhaupt dann noch verwendet werden?
Bis denn, Gruß
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Das kommt wirklich auf die ART deiner Anwendung an:
Der CL_GUI_DIALOGBOX_CONTAINER ist ohne zusätzlichen Parameter AMODAL, sprich du kannst im Hauptfenster noch Dinge verändern.
Ist insofern Cool, als dass du den Dialog auf einen zweiten Bildschirm verschieben kannst (natürlich sofern vorhanden ;P )
Dasselbe gilt auch für den CL_GUI_DOCKING_CONTAINER, nur das er nicht in einem eigenen Fenster aufgeht, sondern sich oben, links, recht oder unten an das bestehende "andockt".
CALL SCREEN würd ich machen, wenn du verhindern(!) möchtest, dass man etwas an der ursprünglichen Auswahl im ersten ALV, die das zweite ALV aufgerufen hat, verändern darf. CALL SCREEN mit STARTING/ENDING wäre übrigens ein MODALES Dialogfenster.
lg ADT
Das kommt wirklich auf die ART deiner Anwendung an:
Der CL_GUI_DIALOGBOX_CONTAINER ist ohne zusätzlichen Parameter AMODAL, sprich du kannst im Hauptfenster noch Dinge verändern.
Ist insofern Cool, als dass du den Dialog auf einen zweiten Bildschirm verschieben kannst (natürlich sofern vorhanden ;P )
Dasselbe gilt auch für den CL_GUI_DOCKING_CONTAINER, nur das er nicht in einem eigenen Fenster aufgeht, sondern sich oben, links, recht oder unten an das bestehende "andockt".
CALL SCREEN würd ich machen, wenn du verhindern(!) möchtest, dass man etwas an der ursprünglichen Auswahl im ersten ALV, die das zweite ALV aufgerufen hat, verändern darf. CALL SCREEN mit STARTING/ENDING wäre übrigens ein MODALES Dialogfenster.
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,
nun ist es ja so, dass es sich eigentlich um einen Subscreen handelt. Daher wollte ich den Aufruf mit 'CALL SUBSCREEN' machen. Da musste ich jetzt aber leider feststellen, dass der Aufruf 'CALL SUBSCREEN' nur im PBO-Block erlaubt ist. Ich möchte den Subscreen jedoch in meiner Methode 'on_doubleklick' aufrufen.
Bei einem 'CALL SCREEN' Aufruf kommt es (verständlicherweise) zu einem Laufzeitfehler, da ich ja angegeben hab, dass es sich um einen Subscreen handelt.
Kannst du mir nochmals weiterhelfen?
Viele Grüße
nun ist es ja so, dass es sich eigentlich um einen Subscreen handelt. Daher wollte ich den Aufruf mit 'CALL SUBSCREEN' machen. Da musste ich jetzt aber leider feststellen, dass der Aufruf 'CALL SUBSCREEN' nur im PBO-Block erlaubt ist. Ich möchte den Subscreen jedoch in meiner Methode 'on_doubleklick' aufrufen.
Bei einem 'CALL SCREEN' Aufruf kommt es (verständlicherweise) zu einem Laufzeitfehler, da ich ja angegeben hab, dass es sich um einen Subscreen handelt.
Kannst du mir nochmals weiterhelfen?
Viele Grüße
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Subscreens werden (wie der Name schon andeutet) innerhalb eines bestehenden Screens eingebunden.
Du musst in deinem Screen also einen Subscreen-Bereich festlegen und im PBO Abschnitt der Ablauflogik mittels CALL SUBSCREEN die Dynpronummer/Programmnamen mitgeben.
Oder du veränderst dein Subscreen-Dynpro und machst es zu einem "normalen" Dynpro. Dann kannst du es mit CALL SCREEN wie gewohnt aufrufen.
Subscreens werden oft für immer wiederkehrende Abschnitte verwendet. z.B. einen Login mit Benutzername und Passwort, der immer die gleiche Funktion haben soll, aber in unterschiedlichen Kontexten aufgerufen wird und mal mehr zusatzfelder ("Bitte registrieren") und mal weniger ("Sicherheitsüberprüfung") benötigt.
In deinem Fall ist ein Subscreen falsch, da er sobald existent eigentlich immer angezeigt wird und du willst ja, dass er erst nach Auswahl eines Eintrages erscheint.
Ich glaube auch du hast das mit dem Subscreen (namentlich) falsch intepretiert. Hierbei handelt es sich nicht um einen Bildschirm der von einem anderen aus aufgerufen wird. Was du unter dem Namen "gesucht" hast, ist eigentlich die Dynprofolge ("Folgedynpro"). Hier wird angegeben welches Dynpro nachdem man das aktuelle verlassen hat, als nächstes aufgerufen wird. Siehe dazu auch den Befehl LEAVE SCREEN.
lg
ADT
Subscreens werden (wie der Name schon andeutet) innerhalb eines bestehenden Screens eingebunden.
Du musst in deinem Screen also einen Subscreen-Bereich festlegen und im PBO Abschnitt der Ablauflogik mittels CALL SUBSCREEN die Dynpronummer/Programmnamen mitgeben.
Oder du veränderst dein Subscreen-Dynpro und machst es zu einem "normalen" Dynpro. Dann kannst du es mit CALL SCREEN wie gewohnt aufrufen.
Subscreens werden oft für immer wiederkehrende Abschnitte verwendet. z.B. einen Login mit Benutzername und Passwort, der immer die gleiche Funktion haben soll, aber in unterschiedlichen Kontexten aufgerufen wird und mal mehr zusatzfelder ("Bitte registrieren") und mal weniger ("Sicherheitsüberprüfung") benötigt.
In deinem Fall ist ein Subscreen falsch, da er sobald existent eigentlich immer angezeigt wird und du willst ja, dass er erst nach Auswahl eines Eintrages erscheint.
Ich glaube auch du hast das mit dem Subscreen (namentlich) falsch intepretiert. Hierbei handelt es sich nicht um einen Bildschirm der von einem anderen aus aufgerufen wird. Was du unter dem Namen "gesucht" hast, ist eigentlich die Dynprofolge ("Folgedynpro"). Hier wird angegeben welches Dynpro nachdem man das aktuelle verlassen hat, als nächstes aufgerufen wird. Siehe dazu auch den Befehl LEAVE SCREEN.
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,
So ganz steig ich hier noch nicht durch. Ich hab mir jetzt mal das Beispiel 'DEMO_ABAP_OBJECTS_SPLIT_SCREEN' angeschaut, das meinem Programm ähnelt.
Allerdings habe ich bislang keine Transferleistung hinbekommen. =/
Im 'DEMO_ABAP_OBJECTS_SPLIT_SCREEN' Beispiel haben wir zum einen diesen Tree, der meinem ersten ALV ähnelt (wird zum Programmstart initialisiert; ändert sich nicht zur Laufzeit; bei einem Doppelklick wird ein weiteres Element (ALV) erzeugt.
In diesem Beispiel wird die Klasse 'CL_GUI_SPLITTER_CONTAINER' verwendet, die du bisher noch nicht angesprochen hattest. Dennoch verwendbar für meine Bedürfnisse?
Und mein zweites ALV entspricht im Grunde diesem rechten Container. Allerdings sollte dieser erst beim ersten Doppelklick zu sehen sein und nicht schon von Programmstart. Kann man dieses Verhalten ausschalten?
Hinzu kommt, dass mein zweites ALV für Änderungen offen sein muss.
Gibts vllt. noch einen im Standard vorhandenen, auf ABAP Objects basierenden Report, der meinen Wünschen entspricht, damit ich mir das nochmals anschauen kann?
Gruß
Wenn man einen Subscreen einbindet und das im PBO Abschnitt definieren muss, dann habe ich ja aber das Problem, dass der Subscreen auf jeden Fall aufgerufen wird. Eigentlich möchte ich das ja durch einen Double-Klick Event aufrufen.a-dead-trousers hat geschrieben:Subscreens werden (wie der Name schon andeutet) innerhalb eines bestehenden Screens eingebunden.
Du musst in deinem Screen also einen Subscreen-Bereich festlegen und im PBO Abschnitt der Ablauflogik mittels CALL SUBSCREEN die Dynpronummer/Programmnamen mitgeben.
Mh....dann kann ich es zwar wie ein "normales" Dynpro aufrufen, aber damit befinden sich doch die beiden Dynpros/ALVs nicht auf der selben Bildschirmmaske?!a-dead-trousers hat geschrieben:Oder du veränderst dein Subscreen-Dynpro und machst es zu einem "normalen" Dynpro. Dann kannst du es mit CALL SCREEN wie gewohnt aufrufen.
So ganz steig ich hier noch nicht durch. Ich hab mir jetzt mal das Beispiel 'DEMO_ABAP_OBJECTS_SPLIT_SCREEN' angeschaut, das meinem Programm ähnelt.
Allerdings habe ich bislang keine Transferleistung hinbekommen. =/
Im 'DEMO_ABAP_OBJECTS_SPLIT_SCREEN' Beispiel haben wir zum einen diesen Tree, der meinem ersten ALV ähnelt (wird zum Programmstart initialisiert; ändert sich nicht zur Laufzeit; bei einem Doppelklick wird ein weiteres Element (ALV) erzeugt.
In diesem Beispiel wird die Klasse 'CL_GUI_SPLITTER_CONTAINER' verwendet, die du bisher noch nicht angesprochen hattest. Dennoch verwendbar für meine Bedürfnisse?
Und mein zweites ALV entspricht im Grunde diesem rechten Container. Allerdings sollte dieser erst beim ersten Doppelklick zu sehen sein und nicht schon von Programmstart. Kann man dieses Verhalten ausschalten?
Hinzu kommt, dass mein zweites ALV für Änderungen offen sein muss.
Gibts vllt. noch einen im Standard vorhandenen, auf ABAP Objects basierenden Report, der meinen Wünschen entspricht, damit ich mir das nochmals anschauen kann?
Gruß
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Der CL_GUI_SPLITTER_CONTAINER "teilt" (wie der Name schon vermuten lässt) einen (Custom-)Container in mehrere Untercontainer auf.
Folgende Variante wäre aus deiner Aufgabenstellung (BEIDE ALVs gleichzeitig anzeigen) vorstellbar:
Du verwendest den Aufbau von DEMO_ABAP_OBJECTS_SPLIT_SCREEN und setzt Anfangs die Breite (CL_GUI_SPLITTER_CONTAINER->SET_COLUMN_WIDTH) des Bereiches wo das Detail-ALV angezeigt wird auf 0. Sobald ein Doppelklick passiert setzt du die Breite auf z.B. 50
Den SASH musst du dann ggbf. ein- bzw. ausblenden.
lg ADT
Der CL_GUI_SPLITTER_CONTAINER "teilt" (wie der Name schon vermuten lässt) einen (Custom-)Container in mehrere Untercontainer auf.
Folgende Variante wäre aus deiner Aufgabenstellung (BEIDE ALVs gleichzeitig anzeigen) vorstellbar:
Du verwendest den Aufbau von DEMO_ABAP_OBJECTS_SPLIT_SCREEN und setzt Anfangs die Breite (CL_GUI_SPLITTER_CONTAINER->SET_COLUMN_WIDTH) des Bereiches wo das Detail-ALV angezeigt wird auf 0. Sobald ein Doppelklick passiert setzt du die Breite auf z.B. 50
Den SASH musst du dann ggbf. ein- bzw. ausblenden.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
newbie007
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
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2012
Views
Views
2
Antw.
Antw.
2733
Views
Views
0
Antw.
Antw.
1409
Views
Views
2
Antw.
Antw.
2287
Views
Views
Exception Handler + Fehlerpopup
von sidneyweiher » 26.01.2015 10:43 • Verfasst in ABAP® für Anfänger
von sidneyweiher » 26.01.2015 10:43 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1224
vor 3 Tagen von DeathAndPain 4 / 1224
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 3 Tagen von DeathAndPain 4 / 1224
vor 3 Tagen von DeathAndPain 4 / 1224