Verlassen Dynpro?!
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
Weiß einer, wenn ich von Dynpro 2 zu Dynpro 1 zurückspringe, wie ich einen Tree in einem TreeControl sowie einen GridControl lösche ohne
daß dann der alte Tree und die alten Daten im Grid zu sehen sind ,wenn ich mit anderen Bedingungen wieder mit in Dynpro 2 springe.
Bei der Methode container->free kommt der Dump Objectreferenz zeigt auf null!
Es funktioniert nur, wenn ich aus der TA komplett raus und wieder reinspringe.
daß dann der alte Tree und die alten Daten im Grid zu sehen sind ,wenn ich mit anderen Bedingungen wieder mit in Dynpro 2 springe.
Bei der Methode container->free kommt der Dump Objectreferenz zeigt auf null!
Es funktioniert nur, wenn ich aus der TA komplett raus und wieder reinspringe.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hi eschi,
komme aus der Java welt und arbeite mich grade in ABAP bzw. ABAPOO ein. deshalb bin ich mir nicht sicher ob das so funktioniert.
Aber warum die free methode aufrufen wenn du einfach eine referenz auf ein anderes objekt übergeben kannst. bin mir eben nicht sicher ob das bei ABAPOO geht.
Du erstellst dir zwei trees und übergibst nur den tree den du auch sehen möchtest.
Gruß Felix
ps: die Brockhaus PDFs in der Tutorialsection sind klasse!!! Danke!
komme aus der Java welt und arbeite mich grade in ABAP bzw. ABAPOO ein. deshalb bin ich mir nicht sicher ob das so funktioniert.
Aber warum die free methode aufrufen wenn du einfach eine referenz auf ein anderes objekt übergeben kannst. bin mir eben nicht sicher ob das bei ABAPOO geht.
Du erstellst dir zwei trees und übergibst nur den tree den du auch sehen möchtest.
Gruß Felix
ps: die Brockhaus PDFs in der Tutorialsection sind klasse!!! Danke!
Normalerweise refresht man den Tree, wenn man aktuelle Daten anzeigen möchte.
Wahlweise kann man ihn auch abbauen und neu instanzieren. Aufpassen muss man auch mit der lifetime, die man bei der Instanzierung der Controls mitgeben kann. Hier sind verschiedene Werte möglich:
lifetime_imode : Das Control lebt, solange der interne Modus nicht abgebaut wird (z.B.: leave program. leave transaction. set screen 0, leave screen. ). Danach wird die Methode finalize aufgerufen
lifetime_dynpro : Das Control lebt, solange die Instanz des Dynpros existiert, d.h. sich noch im Dynprostapel befindet. Danach wird die Methode free aufgerufen.
Die Benutzung dieses Modus regelt automatisch die Sichtbarkeit von Controls. Controls werden immer nur dann eingeblendet, wenn das Dynpro aktiv ist, auf dem sie erzeugt wurden. Ist ein anderes Dynpro aktiv, werden sie automatisch unsichtbar geschaltet.
lifetime_default : Wird das Control in einen Container eingebaut, übernimmt es die Lebensdauer des Containers. Wird es nicht in einen Container eingebaut (z.B. weil es selbst ein Container ist), dann wird die Lebensdauer auf lifetime_imode gesetzt.
Grüssle
Norbert
Wahlweise kann man ihn auch abbauen und neu instanzieren. Aufpassen muss man auch mit der lifetime, die man bei der Instanzierung der Controls mitgeben kann. Hier sind verschiedene Werte möglich:
lifetime_imode : Das Control lebt, solange der interne Modus nicht abgebaut wird (z.B.: leave program. leave transaction. set screen 0, leave screen. ). Danach wird die Methode finalize aufgerufen
lifetime_dynpro : Das Control lebt, solange die Instanz des Dynpros existiert, d.h. sich noch im Dynprostapel befindet. Danach wird die Methode free aufgerufen.
Die Benutzung dieses Modus regelt automatisch die Sichtbarkeit von Controls. Controls werden immer nur dann eingeblendet, wenn das Dynpro aktiv ist, auf dem sie erzeugt wurden. Ist ein anderes Dynpro aktiv, werden sie automatisch unsichtbar geschaltet.
lifetime_default : Wird das Control in einen Container eingebaut, übernimmt es die Lebensdauer des Containers. Wird es nicht in einen Container eingebaut (z.B. weil es selbst ein Container ist), dann wird die Lebensdauer auf lifetime_imode gesetzt.
Grüssle
Norbert
...........
Just do it !
Just do it !
Hallo zusammen,
ich habe das Problem mit LEAVE TO TRANSACTION gelöst.
Trotzdem danke.
Jetzt habe ich ein neues Problem:
Ich rufe per Doppelklick auf einen Node im Tree verschiedene Grids auf. Wenn ich eine Zeile markiere, kann ich per Button in Dynpro 3 springen. Das Problem ist, wenn ich eine Zeile markiert habe, in Dynpro 3 springe, wieder zurückgehe auf ein anderes Grid per Doppelklick gehe, dann wieder auf das Grid mit der markierten Zeile und den Button drücke, erkennt das Grid die Markierung nicht. Die Methode get_selected_rows liefert dann eine leere interne Tabelle irows zurück. Es funktioniert auch nicht, wenn ich die Zeile entmarkiere und wieder markiere.[/i]
ich habe das Problem mit LEAVE TO TRANSACTION gelöst.
Trotzdem danke.
Jetzt habe ich ein neues Problem:
Ich rufe per Doppelklick auf einen Node im Tree verschiedene Grids auf. Wenn ich eine Zeile markiere, kann ich per Button in Dynpro 3 springen. Das Problem ist, wenn ich eine Zeile markiert habe, in Dynpro 3 springe, wieder zurückgehe auf ein anderes Grid per Doppelklick gehe, dann wieder auf das Grid mit der markierten Zeile und den Button drücke, erkennt das Grid die Markierung nicht. Die Methode get_selected_rows liefert dann eine leere interne Tabelle irows zurück. Es funktioniert auch nicht, wenn ich die Zeile entmarkiere und wieder markiere.[/i]
Sorry, aber Du scheinst die quick-and-dirty Varianten zu bevorzugen.
Gerade im doch sehr komplexen Controls-Umfeld ist es jedoch wichtig zu verstehen, was genau abläuft, welches Control zu welcher Zeit gültig ist etc.
Ansonsten sind solche side-effects, wie Du sie im 2.ten Problem beschreibst, an der Tagesordnung.
(Ich spreche da aus Erfahrung
)
Problem ist nach der Beschreibung jedenfalls kaum nachzuvollziehen. Dafür ist es zu kurz und durcheinander dargestellt. Denke daran, dass man sich ohne Screenshot & Coding in ein fremdes Problem eindenken soll - und das in einer überschaubaren Zeit.
Viele Grüsse
Norbert
Gerade im doch sehr komplexen Controls-Umfeld ist es jedoch wichtig zu verstehen, was genau abläuft, welches Control zu welcher Zeit gültig ist etc.
Ansonsten sind solche side-effects, wie Du sie im 2.ten Problem beschreibst, an der Tagesordnung.
(Ich spreche da aus Erfahrung
)Problem ist nach der Beschreibung jedenfalls kaum nachzuvollziehen. Dafür ist es zu kurz und durcheinander dargestellt. Denke daran, dass man sich ohne Screenshot & Coding in ein fremdes Problem eindenken soll - und das in einer überschaubaren Zeit.
Viele Grüsse
Norbert
...........
Just do it !
Just do it !
Hallo Norbert,
ok, ich versuche dir mal konkreter zu beschreiben, was ich für ein Problem habe.
Ich habe auf der linken Seite meines Dynpro's einen
ListTree! Auf der rechten Seite wird per Doppelklick
auf einen Node des Tree's ein ALV erstellt. Je nach Doppelklick wird eine neue Tabelle in das Grid geladen. Jedes dieser Grid's steht auf einem Subscreen, der per PBO dort reingeladen wird.
Desweiteren habe ich auf jedem ALV einen Button hinzugefügt, den, wenn eine Zeile markiert ist, man betätigen kann, um in ein anderes Dynpro zu springen.
Das klappt beim ersten Mal auch. Wenn ich allerdings aus dem Dynpro zurückspringe und auf dem Tree ein anderes Grid per Doppelklick aufrufe und ich dort eine Zeile markiere, so erkennt die Methode get_selected_rows diese Markierung nicht.
Hilft es hierbei vielleicht, den LifetimeParameter des Grid's auf Lifetime-dynpro wie du es oben beschrieben hast zustellen???
[/code]
ok, ich versuche dir mal konkreter zu beschreiben, was ich für ein Problem habe.
Ich habe auf der linken Seite meines Dynpro's einen
ListTree! Auf der rechten Seite wird per Doppelklick
auf einen Node des Tree's ein ALV erstellt. Je nach Doppelklick wird eine neue Tabelle in das Grid geladen. Jedes dieser Grid's steht auf einem Subscreen, der per PBO dort reingeladen wird.
Desweiteren habe ich auf jedem ALV einen Button hinzugefügt, den, wenn eine Zeile markiert ist, man betätigen kann, um in ein anderes Dynpro zu springen.
Das klappt beim ersten Mal auch. Wenn ich allerdings aus dem Dynpro zurückspringe und auf dem Tree ein anderes Grid per Doppelklick aufrufe und ich dort eine Zeile markiere, so erkennt die Methode get_selected_rows diese Markierung nicht.
Hilft es hierbei vielleicht, den LifetimeParameter des Grid's auf Lifetime-dynpro wie du es oben beschrieben hast zustellen???
[/code]
Zu welchem Zeitpunkt rufst Du besagte Methode denn auf ?
PAI des jeweiligen Grid-Subscreens ? Benutzt du das richtige Grid-Objekt für den Methodenaufruf ?
Vielleicht solltest Du die Lebensdauer des GridControls wirklich an das Dynpro binden.
Gruss
Norbert
PAI des jeweiligen Grid-Subscreens ? Benutzt du das richtige Grid-Objekt für den Methodenaufruf ?
Vielleicht solltest Du die Lebensdauer des GridControls wirklich an das Dynpro binden.
Gruss
Norbert
...........
Just do it !
Just do it !
Sieht soweit gut aus.
Werden die Container/Grids bei jedem Durchlauf
instanziert ?
Vielleicht nur beim ersten Aufruf instanzieren:
if not container_ap is initial.
...
Grid instanzieren
Events setzen
...
endif.
Werden die Container/Grids bei jedem Durchlauf
instanziert ?
Vielleicht nur beim ersten Aufruf instanzieren:
if not container_ap is initial.
...
Grid instanzieren
Events setzen
...
endif.
...........
Just do it !
Just do it !
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2665
Views
Views
2
Antw.
Antw.
1957
Views
Views
8
Antw.
Antw.
4164
Views
Views
4
Antw.
Antw.
4262
Views
Views
Report vor Selektion verlassen
von dermannvomberg » 07.10.2010 10:50 • Verfasst in Dialogprogrammierung
von dermannvomberg » 07.10.2010 10:50 • Verfasst in Dialogprogrammierung
1
Antw.
Antw.
3903
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.