ralf.wenzel hat geschrieben:Außerdem kann man da sicherlich was mit structdescr / describe by data was machen. Ich werde das beizeiten mal testen....
Naja, solange kein DDIC-Bezug (per Name) besteht, bleiben meines Wissens nur zwei Möglichkeiten:
ENTWEDER die Einstellungen aus dem Dynpro auslesen (IMPORT DYNPRO)
ODER mittels Dirty-Assign die entsprechende Variable aus dem Programm holen und darauf den Typedescr anwenden.
Aber die erste Variante benutzt einen von der SAP "nicht erlaubten" Befehl und bei der zweiten brauchst du erst wieder eine Variable im Programm und damit ist der ganze DYNP_READ_VALUES Kram unnötig, weil dann (bis auf POV und POH) der Feldtransport sowieso funktioniert.
Die bislang beste Lösung um die Felder eines Dynpros in einer Klasse möglichst effizient zu nutzen, hat meines erachten ein Kollege von mir entdeckt:
In der Klasse für alle Felder des Dynpros ein statisches(!) Attribut und im Dynpro darauf mittels "KLASSE=>ATTRIBUT" Bezug nehmen.
Der große Vorteil ist, dass man im Programm in dem die Dynpros liegen, keine Variablen mehr benötigt. Wenn man die PAI/PBO/POV/POH-Module für die Verarbeitung dann noch in ein Include auslagert das dann in mehrere Programme eingebunden werden kann, besteht jedes neue Trägerprogram für die Dynpros nur aus zwei Zeilen Code. Einzige Ausnahme bleibt, wenn man Table-Controls oder Tabstrips verwendet, dass man nach wie vor auch die CONTROLS-Anweisung im Programm benötigt.
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