Wie funktionieren Dynpros
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo zusammen,
irgendwie kollidiert mein Verständniss von der Funktionsweise der Dynpros mit der Realität. Ich habe einen Dynpro 9001 mit nichts außer einem Custom Control namens 'CONTAINER'. Dieser Dynpro wird aufgerufen aus einem FUBA mit CALL SCREEN.
Im PBO von 9001 wird ein cl_gui_custom_container an den Custom Control des Dynpros angebunden und diesem Custom Container wird ein cl_gui_simple_tree angezeigt. Zudem gibts im PBO einen alternativen Ausführungspfad bei dem der Container und der Baum einfach auf Initialwerte gesetzt werden. Hier der Code:
Wenn der PBO ein mal durchläuft, dann erscheint ein Pop-Up mit den zwei Knoten. Alles soweit wie erwartet. Jetzt triggere ich aber nochmal den PBO und setze im Debugger den Wert von gv_execution auf fail. Der Container und der Tree werden auf ihre Initialwerte zurückgesetzt, aber im Pop-Up erscheint weiterhin die Baumstruktur wie wenn nichts gewesen wäre.
1. Frage: Warum wird beim zweiten Bildschirmaufbau die Initialisierung ignoriert ( ohne einen Fehler oder einen Hinweis )? Ich meine der Code wird durchalufen, aber das Resultat ist so, als wenn er nicht durchlaufen worden wäre. Was soll das?
2. Frage: Offensichtlich gibts bei den Dynpros irgendwelche Buffer-Mechaniken. Kann mir da jemand einen Hinweis geben wonach ich da googeln soll, oder mir diese erklären?
(Falls jemand noch den restlichen Code sehen will, gebt bitte Bescheid und ich reiche ihn nach. )
Danke im Voraus!
irgendwie kollidiert mein Verständniss von der Funktionsweise der Dynpros mit der Realität. Ich habe einen Dynpro 9001 mit nichts außer einem Custom Control namens 'CONTAINER'. Dieser Dynpro wird aufgerufen aus einem FUBA mit CALL SCREEN.
Im PBO von 9001 wird ein cl_gui_custom_container an den Custom Control des Dynpros angebunden und diesem Custom Container wird ein cl_gui_simple_tree angezeigt. Zudem gibts im PBO einen alternativen Ausführungspfad bei dem der Container und der Baum einfach auf Initialwerte gesetzt werden. Hier der Code:
Code: Alles auswählen.
MODULE 9001_pbo OUTPUT.
CLEAR main_container.
CREATE OBJECT main_container
EXPORTING
container_name = 'CONTAINER'.
IF node_tab IS INITIAL.
APPEND VALUE t_tree( node_key = '1'
relatkey = ' '
relatship = 0
text = 'node 1' ) TO node_tab.
APPEND VALUE t_tree( node_key = '2'
relatkey = ' '
relatship = 0
text = 'node 2' ) TO node_tab.
ENDIF.
BREAK-POINT. "hier kann man gv_execution umschalten
CASE gv_execution.
WHEN c_as_usual.
* das ist der normale Ausführungspfad. Tree wird erstellt und gezeichnet.
CLEAR tree.
CREATE OBJECT tree
EXPORTING
parent = main_container
node_selection_mode = cl_gui_simple_tree=>node_sel_mode_single.
tree->add_nodes( node_table = node_tab
table_structure_name = 'MTREESNODE' ).
CREATE OBJECT event_handler.
IF event_tab IS INITIAL.
APPEND VALUE #( eventid = cl_gui_simple_tree=>eventid_selection_changed
appl_event = ' ' ) TO event_tab.
ENDIF.
tree->set_registered_events( events = event_tab ).
SET HANDLER event_handler->handle_selection_changed FOR tree.
WHEN c_fail.
* das ist ein fehlerhafter Ausführungspfad. Container und Tree sind initial. Es müsste also dumpen, oder nichts anzeigen, oder?
FREE: main_container,
tree.
ENDCASE.
ENDMODULE.
1. Frage: Warum wird beim zweiten Bildschirmaufbau die Initialisierung ignoriert ( ohne einen Fehler oder einen Hinweis )? Ich meine der Code wird durchalufen, aber das Resultat ist so, als wenn er nicht durchlaufen worden wäre. Was soll das?
2. Frage: Offensichtlich gibts bei den Dynpros irgendwelche Buffer-Mechaniken. Kann mir da jemand einen Hinweis geben wonach ich da googeln soll, oder mir diese erklären?
(Falls jemand noch den restlichen Code sehen will, gebt bitte Bescheid und ich reiche ihn nach. )
Danke im Voraus!
Zuletzt geändert von sapnup am 05.09.2017 17:48, insgesamt 1-mal geändert.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Wir brauchen definitiv einen Sticky-Thread für das Thema "Mehrere Controls in einem Container".
Du machst zwar ein FREE auf deinen Container und Bäumchen, aber da das alles noch angezeigt wird, existiert immer noch ein Verweis auf die inzwischen von deinem Programm nicht mehr ansprechbaren Controls.
Das ist das selbe, wie das häufig gepostete Problem, dass ein ALV neu aufgebaut wird, aber die neuen Werte einfach nicht angezeigt werden.
Du machst zwar ein FREE auf deinen Container und Bäumchen, aber da das alles noch angezeigt wird, existiert immer noch ein Verweis auf die inzwischen von deinem Programm nicht mehr ansprechbaren Controls.
Das ist das selbe, wie das häufig gepostete Problem, dass ein ALV neu aufgebaut wird, aber die neuen Werte einfach nicht angezeigt werden.
Hallo zzcpak, danke für den Hinweis auf "SUPPRESS DIALOG". Leider hilft es mir nicht weiter. Mein Problem ist folgendes:
Ich stelle mir die Dynpro-Abarbeitung folgender Maßen vor:
1. PBO-Code wird ausgeführt. Wenn hier die Controls manipuliert werden, dann werden diese Manipulationen zwingend auf dem folgenen Dialogbildschirm sichtbar sein (oder es gibt zumindestens einen dump)
2. Dialogbildschirm erscheint. Wenn im PBO ein Control hinzugefügt wurde, dann ist dieses Control hier zu sehen. Wenn im PBO ein Control zerstört wurde, dann ist dieses Control hier nicht zu sehen.
3. PAI-Code wird ausgeführt. Siehe PBO ... (warum man einen Code-Block vor und einen nach dem Dialog braucht erschließt sich mir zwar nicht, es wird aber irgendwelche SAP-eigenen Gründe haben)
4. Wenn der Dynpro nicht verlassen wird, Beginnt der Prozess wieder bei Schritt 1.
Diese Vorstellung scheint aber nicht ganz zu stimmen.
In meinem obigen Code halte ich PBO an und lege (mit gv_execution) fest ob der Tree-Control sinnvoll befüllt wird, oder ob der Tree-Control und der Container beide auf den Initialwert gesetzt werden. Entsprechend erwarte ich, dass in einem Durchlauf mit gv_execution = as_usual er Baum im Dialogbildschirm angezeigt wird und in einem Durchlauf mit gv_execution = fail entweder ein leerer Dialogbildschirm kommt oder ein Dump. Es passiert aber etwas anderes:
1. Durchlauf: mit gv_execution = as_usual => Baum wird angezeigt.
Folgedurchlauf mit gv_execution = fail => Baum wird noch immer angezeigt
oder
1. Durchlauf: mit gv_execution = fail => Baum wird nicht angezeigt.
Folgedurchlauf mit gv_execution = as_usual => Baum wird noch immer nicht angezeigt
Das macht für mich keinen Sinn.
Ich stelle mir die Dynpro-Abarbeitung folgender Maßen vor:
1. PBO-Code wird ausgeführt. Wenn hier die Controls manipuliert werden, dann werden diese Manipulationen zwingend auf dem folgenen Dialogbildschirm sichtbar sein (oder es gibt zumindestens einen dump)
2. Dialogbildschirm erscheint. Wenn im PBO ein Control hinzugefügt wurde, dann ist dieses Control hier zu sehen. Wenn im PBO ein Control zerstört wurde, dann ist dieses Control hier nicht zu sehen.
3. PAI-Code wird ausgeführt. Siehe PBO ... (warum man einen Code-Block vor und einen nach dem Dialog braucht erschließt sich mir zwar nicht, es wird aber irgendwelche SAP-eigenen Gründe haben)
4. Wenn der Dynpro nicht verlassen wird, Beginnt der Prozess wieder bei Schritt 1.
Diese Vorstellung scheint aber nicht ganz zu stimmen.
In meinem obigen Code halte ich PBO an und lege (mit gv_execution) fest ob der Tree-Control sinnvoll befüllt wird, oder ob der Tree-Control und der Container beide auf den Initialwert gesetzt werden. Entsprechend erwarte ich, dass in einem Durchlauf mit gv_execution = as_usual er Baum im Dialogbildschirm angezeigt wird und in einem Durchlauf mit gv_execution = fail entweder ein leerer Dialogbildschirm kommt oder ein Dump. Es passiert aber etwas anderes:
1. Durchlauf: mit gv_execution = as_usual => Baum wird angezeigt.
Folgedurchlauf mit gv_execution = fail => Baum wird noch immer angezeigt
oder
1. Durchlauf: mit gv_execution = fail => Baum wird nicht angezeigt.
Folgedurchlauf mit gv_execution = as_usual => Baum wird noch immer nicht angezeigt
Das macht für mich keinen Sinn.
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Dein Problem ist, dass du das Control eben NICHT zerstörst. Dein Free bewirkt nichts, da noch eine Referenz auf das Control besteht.
Das kannst du folgendermaßen überprüfen: Schau dir im Debugger dein CustomControl an und dort was im Attribut PARENT gespeichert ist. Dieser PARENT-Container hat nun eine Child-Liste, in der dein CustomContainer drin steht.
Wenn du dein FREE machst, wird zwar deine Referenzvariable, die auf den CustomContainer zeigt gelöscht - aber der Zeiger auf das Control bleibt immer noch in der Childliste des PARENT bestehen. Wenn du jetzt einen neuen Container und Baum erzeugst, werden diese zusätzlich in dem PARENT registriert - aber "hinter" dem zuerst registrierten und daher nicht angezeigt.
Das kannst du auch leicht testen, indem du vor deinem FREE ein "SET_VISIBLE( abap_false )" für den CustomContainer machst. Dann bleibt der zwar immer noch im PARENT bestehen, aber da er jetzt unsichtbar ist, kann danach das nächste aufgebaute control angezeigt werden. ABER - Diese Vorgehensweise ist nur zu Demozwecken zu gebrauchen. Das eigentliche Problem des vollständigen Abbaus des Controls hast du damit nicht gelöst.
Das kannst du folgendermaßen überprüfen: Schau dir im Debugger dein CustomControl an und dort was im Attribut PARENT gespeichert ist. Dieser PARENT-Container hat nun eine Child-Liste, in der dein CustomContainer drin steht.
Wenn du dein FREE machst, wird zwar deine Referenzvariable, die auf den CustomContainer zeigt gelöscht - aber der Zeiger auf das Control bleibt immer noch in der Childliste des PARENT bestehen. Wenn du jetzt einen neuen Container und Baum erzeugst, werden diese zusätzlich in dem PARENT registriert - aber "hinter" dem zuerst registrierten und daher nicht angezeigt.
Das kannst du auch leicht testen, indem du vor deinem FREE ein "SET_VISIBLE( abap_false )" für den CustomContainer machst. Dann bleibt der zwar immer noch im PARENT bestehen, aber da er jetzt unsichtbar ist, kann danach das nächste aufgebaute control angezeigt werden. ABER - Diese Vorgehensweise ist nur zu Demozwecken zu gebrauchen. Das eigentliche Problem des vollständigen Abbaus des Controls hast du damit nicht gelöst.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
sapnup
Beitrag
von DeathAndPain (Top Expert / 1948 / 258 /
413
)
»
Ich meine mich zu erinnern, dass ich vor Jahren auch mal vor dem Problem gestanden habe. Gab es da nicht irgendeine Flush- oder Refresh-Methode für?black_adept hat geschrieben:Wir brauchen definitiv einen Sticky-Thread für das Thema "Mehrere Controls in einem Container".
Das ist das selbe, wie das häufig gepostete Problem, dass ein ALV neu aufgebaut wird, aber die neuen Werte einfach nicht angezeigt werden.
söööö, den Erklärungen von BA folgend habe ich folgenden Code im PAI eingebaut.
wobei control_tab type table of ref to cl_gui_simple_tree und <control> ein entsprechendes Feldsymbol ist. Und siehe da. In jedem PAI füge ich einen neue Control zu der Tabelle hinzu. Und wenn ich nun den ersten Eintrag der Tabelle auslese und auf ihm Änderungen vornehme (z.B. Knoten löschen, neue Knoten einfügen, ->free( ) aufrufen, etc) dann werden diese Änderungen auch im Dialogbildschirm sichtbar. ( Mit der Methode free() zerstöre ich wohl auch das Control endgültig. Zumindestens ist es mir danach nicht mehr möglich auf Methoden und Attribute des Controls zuzugreifen. )
Danke, wieder etwas gelernt
Code: Alles auswählen.
READ TABLE control_tab ASSIGNING <control> WITH KEY table_line = tree.
IF sy-subrc <> 0.
APPEND tree TO control_tab.
ENDIF.
Danke, wieder etwas gelernt
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
ARGH,
das hört sich so was von falsch an. Dein Problem war, dass du mehrere GUI-Controls in einem Container hast. Und auch wenn du es jetzt schaffst dir über die Control-Tab den sichtbaren Tree zu beschaffen fängst du trotzdem an diverse Trees aufzubauen, was im Normalfall nie gewünscht ist! Du doktorst also lediglich am Symptom rum statt die Ursache zu bekämpfen.
Ich frage jetzt mal ganz direkt. Hast du vor dem FREE auf die Programmvariable deines Baums auch die Methode "FREE" des Baums aufgerufen ( und nachher ein CL_GUI_CFW=>FLUSH( ) abgesetzt ) um den Baum aus der Childliste seines Parents zu entfernen, so wie man das bei allen GUI-Controls machen sollte wenn man sie sauber abbauen will ( Und was beim SALV-Grid nicht funktioniert, da dieser keine FREE-Methode hat)?
das hört sich so was von falsch an. Dein Problem war, dass du mehrere GUI-Controls in einem Container hast. Und auch wenn du es jetzt schaffst dir über die Control-Tab den sichtbaren Tree zu beschaffen fängst du trotzdem an diverse Trees aufzubauen, was im Normalfall nie gewünscht ist! Du doktorst also lediglich am Symptom rum statt die Ursache zu bekämpfen.
Ich frage jetzt mal ganz direkt. Hast du vor dem FREE auf die Programmvariable deines Baums auch die Methode "FREE" des Baums aufgerufen ( und nachher ein CL_GUI_CFW=>FLUSH( ) abgesetzt ) um den Baum aus der Childliste seines Parents zu entfernen, so wie man das bei allen GUI-Controls machen sollte wenn man sie sauber abbauen will ( Und was beim SALV-Grid nicht funktioniert, da dieser keine FREE-Methode hat)?
Oh entschuldige bitte, ich hatte mich etwas unklar ausgedrückt. Das mit dem Control_Tab war nur eine Spielerei. Im neuen Wissen um diese Problematik habe ich das Anlegen von Gui-Elementen in einen Code-Teil ausgelagert der nur ein Mal durchlaufen wird. Ab da Arbeite ich dann nur noch mit den Methoden die mir die Controls bieten - also beim Baum z.B. Knoten löschen und neu anlegen, statt den ganzen Control jedes mal zu initialisieren.
->free() und CL_GUI_CFW=>FLUSH( ) nutze ich gerade nirgends weil ich die GUIs nicht aktiv abbaue (und weil ich CL_GUI_CFW=>FLUSH( ) nicht kannte). Wobei, jetzt wo du es ansprichst, wie handhabt man es in ABAP mit den GUI-Elementen am Ende des Lebenszyklus einer GUI? Garbage Collector oder alles händisch abbauen?
Und Danke für den gutgemeinten Hinweis.
->free() und CL_GUI_CFW=>FLUSH( ) nutze ich gerade nirgends weil ich die GUIs nicht aktiv abbaue (und weil ich CL_GUI_CFW=>FLUSH( ) nicht kannte). Wobei, jetzt wo du es ansprichst, wie handhabt man es in ABAP mit den GUI-Elementen am Ende des Lebenszyklus einer GUI? Garbage Collector oder alles händisch abbauen?
Und Danke für den gutgemeinten Hinweis.
Beitrag
von black_adept (Top Expert / 4093 / 128 /
940
)
»
Genau so sollte das gemacht werden.sapnup hat geschrieben:Im neuen Wissen um diese Problematik habe ich das Anlegen von Gui-Elementen in einen Code-Teil ausgelagert der nur ein Mal durchlaufen wird. Ab da Arbeite ich dann nur noch mit den Methoden die mir die Controls bieten - also beim Baum z.B. Knoten löschen und neu anlegen, statt den ganzen Control jedes mal zu initialisieren. ...
Meine Faustregel: Abgesehen von OLE2-Objekten lasse ich zum Programmende alles vom Kernel/Garbage-Collector selber abbauen - die machen das ganz gut.sapnup hat geschrieben:... wie handhabt man es in ABAP mit den GUI-Elementen am Ende des Lebenszyklus einer GUI? Garbage Collector oder alles händisch abbauen?
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2234
Views
Views
6
Antw.
Antw.
2898
Views
Views
OO-ALV: Standardfunktionen funktionieren nicht
von Gast » 11.01.2006 08:58 • Verfasst in ABAP Objects®
von Gast » 11.01.2006 08:58 • Verfasst in ABAP Objects®
16
Antw.
Antw.
3371
Views
Views
XML-Views funktionieren leider nicht
von Bright4.5 » 20.09.2023 11:41 • Verfasst in Fiori, UI5, JavaScript
von Bright4.5 » 20.09.2023 11:41 • Verfasst in Fiori, UI5, JavaScript
4
Antw.
Antw.
4391
Views
Views
Funktionstasten für GUI Status funktionieren nicht
von yuro » 15.01.2015 11:02 • Verfasst in ABAP Objects®
von yuro » 15.01.2015 11:02 • Verfasst in ABAP Objects®
4
Antw.
Antw.
2353
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 22 Stunden von ralf.wenzel 104 / 10294
vor 22 Stunden von ralf.wenzel 104 / 10294
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 22 Stunden von ralf.wenzel 104 / 10294
vor 22 Stunden von ralf.wenzel 104 / 10294