Zwei ALV's im Splittercontainer im Default-Screen
a-dead-trousers hat geschrieben:naja, das mit CL_GUI_CONTAINER und dem DEFAULT_SCREEN ist nicht ganz richtig:
- DEFAULT_SCREEN ist das aktuelle Fenster
- SCREEN0..9 sind die dazugehörigen Popup-level des Fensters
- DESKTOP ist wie schon zu erwarten der Windows-Desktop (Hab da auch schon mal was drangehängt)
- Und der WRITE Befehl schreibt in den LISTPROZESSOR (den man vom Dynpro aus mittels PBO - SUPPRESS DIALOG und PAI - LEAVE TO LIST-PROCESSING erreicht) und der ist selbst wieder eine "Art von Dynpro" mit PAI, PBO usw.
Dynpros selbst sind streng genommen keine Fenster im eingentlichen Sinn.
Das sieht man vorallem wenn man sich die Objekthierachie auf seiten von Windows anschaut, da hat nämlich z.B. der Gui-Status und das Dynpro eigene Window-Handles die unter dem eigentlich angezeigten Hauptfenster liegen
Wenn man sich die Verarbeitung von NO_AUTODEF_PROGID_DYNNR anschaut, wird hier versucht, wenn kein PARENT angegeben wurde, das Control mittels LINK auf das aktuelle Dynpro zu verlinken. Das kann aber nur der CL_GUI_CUSTOM_CONTAINER (siehe auch dessen LINK-Methode). Alle anderen Container benötigen immer einen PARENT.
lg ADT
P.S.: Ich weiß, ich weiß, ... Der altkluge Streber soll sich bitte wieder setzen
Erstmal vielen Dank für die sehr hilfreiche und detaillierte Erklärung,auch an alle anderen,die hier gepostet haben!
In Deinem letzten Absatz schreibst Du,dass bei der Option NO_AUTODEF_PROGID_DYNNR versucht wird "das Control mittels LINK auf das aktuelle Dynpro zu verlinken".Unter "Control" verstehe ich die Komponente (Typ Custom Control),die ich (wenn ich ein eigenes Dynpro erzeuge,etwa mit Hilfe des Screen Painters) auf dem Dynpro platziere,um sie später dem Container,den ich in meinem Programm anlege (Typ CL_GUI_CUSTOM_CONTAINER) als Parameter mitzugeben.Wenn ich aber kein Dynpro anlege und den DefaultScreen benutze,dann hab ich ja kein Control,zumindest kriege ich davon nichts mit.Es muss aber ja eins (hinter den Kulissen) geben,ansonsten würde das ja nicht funktionieren.Gibt es eine Möglichkeit,dieses Control aus dem Programm heraus anzusprechen?
Außerdem verstehe ich leider immer noch nicht,warum nichts angezeigt wird,wenn ich NO_AUTODEF_PROGID_DYNNR NICHT benutze.Es gibt ja ausser dem aktuellen Fenster (DefaultScreen) nichts,womit er sich verlinken könnte,also müsste er doch auf jeden Fall (unabhängig von NO_AUTODEF_PROGID_DYNNR) sich mit dem aktuellen Fenster verlinken,oder sehe ich das falsch?
Viele Grüße
J.
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 / 4419 / 224 /
1189
)
»
hi!
Okay ist zwar schon ein wenig Zeit vergangen, aber trotzdem noch eine kurze Erläuterung zu meiner Erklärung:
Als CONTROL meine ich alles was von CL_GUI_CONTROL abgeleitet wurde.
Das CUSTOM CONTROL am Dynpro ist eigentlich nur ein reservierter Platz für die Ausgabe und hat selbst kaum Funktionalitäten.
Als CONTAINER meine ich alles was von CL_GUI_CONTAINER abgeleitet wurde.
Bei einem CUSTOM CONTAINER beziehe ich mich auf die Klasse CL_GUI_CUSTOM_CONTAINER.
So, der LINK den ich erwähnt hab wird eben erst durch den Parameter NO_AUTODEF_PROGID_DYNNR ausgelöst.
Der CL_GUI_CUSTOM_CONTAINER hängt sich eigentlich immer(!) auf das im Parameter NAME angegebene CUSTOM CONTROL (auch bei leer) und generiert trotzdem als Backup sozusagen für sich selbst eine REPID und ein DYNNR. Wozu kann ich leider nicht sagen, da diese Werte intern so gut wie nie verarbeitet werden. Erst bei NO_AUTODEF_PROGID_DYNNR wird dieser Schritt übersprungen und es wird die LINK-Methode ohne NAME aber dafür mit REPID und DYNNR aufgerufen. Ein CONTROL kann auch ohne Anzeigebereich (CUSTOM CONTROL) und ohne Dynpro-LINK exisiteren, was auch meistens der Fall ist, wenn man es nicht sieht
. Dann gibts das in NAME übergebene CUSTOM CONTROL einfach nicht, oder der LINK hat das passende Dynpro nicht gefunden.
Ich würde immer raten, wenn man ohne CUSTOM CONTROL und damit auch ohne spezielles Dynpro arbeiten möchte, trotzdem die Klasse CL_GUI_CUSTOM_CONTAINER als Ausgangsklasse zu verwenden und in dieser dann die anderen CONTAINER und CONTROLs zu platzieren. Dann tut man sich auch leichter wenn man später mal doch (weils einfach besser funktioniert
) auf ein eigenes Dynpro mit CUSTOM CONTROL umsteigt.
hoffe das war jetzt etwas besser erklärt
Okay ist zwar schon ein wenig Zeit vergangen, aber trotzdem noch eine kurze Erläuterung zu meiner Erklärung:
Als CONTROL meine ich alles was von CL_GUI_CONTROL abgeleitet wurde.
Das CUSTOM CONTROL am Dynpro ist eigentlich nur ein reservierter Platz für die Ausgabe und hat selbst kaum Funktionalitäten.
Als CONTAINER meine ich alles was von CL_GUI_CONTAINER abgeleitet wurde.
Bei einem CUSTOM CONTAINER beziehe ich mich auf die Klasse CL_GUI_CUSTOM_CONTAINER.
So, der LINK den ich erwähnt hab wird eben erst durch den Parameter NO_AUTODEF_PROGID_DYNNR ausgelöst.
Der CL_GUI_CUSTOM_CONTAINER hängt sich eigentlich immer(!) auf das im Parameter NAME angegebene CUSTOM CONTROL (auch bei leer) und generiert trotzdem als Backup sozusagen für sich selbst eine REPID und ein DYNNR. Wozu kann ich leider nicht sagen, da diese Werte intern so gut wie nie verarbeitet werden. Erst bei NO_AUTODEF_PROGID_DYNNR wird dieser Schritt übersprungen und es wird die LINK-Methode ohne NAME aber dafür mit REPID und DYNNR aufgerufen. Ein CONTROL kann auch ohne Anzeigebereich (CUSTOM CONTROL) und ohne Dynpro-LINK exisiteren, was auch meistens der Fall ist, wenn man es nicht sieht
. Dann gibts das in NAME übergebene CUSTOM CONTROL einfach nicht, oder der LINK hat das passende Dynpro nicht gefunden.Ich würde immer raten, wenn man ohne CUSTOM CONTROL und damit auch ohne spezielles Dynpro arbeiten möchte, trotzdem die Klasse CL_GUI_CUSTOM_CONTAINER als Ausgangsklasse zu verwenden und in dieser dann die anderen CONTAINER und CONTROLs zu platzieren. Dann tut man sich auch leichter wenn man später mal doch (weils einfach besser funktioniert
) auf ein eigenes Dynpro mit CUSTOM CONTROL umsteigt.hoffe das war jetzt etwas besser erklärt
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
Vergleichbare Themen
1
Antw.
Antw.
4232
Views
Views
Use of BDT - setting default value on the BP screen
von priyanka.bansal » 26.04.2006 11:26 • Verfasst in CRM (Customer Relationship Management)
von priyanka.bansal » 26.04.2006 11:26 • Verfasst in CRM (Customer Relationship Management)
2
Antw.
Antw.
3863
Views
Views
Kein Varianten-Admin im Splitter-Container auf Default Screen
von tonyparzonka » 09.03.2023 12:45 • Verfasst in ABAP Objects®
von tonyparzonka » 09.03.2023 12:45 • Verfasst in ABAP Objects®
3
Antw.
Antw.
323
Views
Views
zwei Pushbuttons in einem screen - sy-subrc16 ?
von sap_koun » 16.06.2022 20:31 • Verfasst in ABAP® für Anfänger
von sap_koun » 16.06.2022 20:31 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
2632
Views
Views
2
Antw.
Antw.
1828
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
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.