dank eines Hinweises von einem Leser hier habe ich das Dynpro entsprechend anpassen können.
Es ist nur höchst unglücklich, dass ich die Standardfelder (welche vorher vorhanden waren) ändern kann - die speichert er auch völlig korrekt in den Standardtabellen - aber wenn ich einen Breakpoint im Dynpro im Bereich "MODULE XXXXX INPUT" setze, sind die Änderungen an den Standardfeldern in den internen Tabellen enthalten - meine kundeneigenen Felder aber leer - ein Eingaben sind "verschwunden", d.h. die Felder sind initial.
Muss ich noch besondere Optionen im Reiter "Element List" berücksichtigen, dass die Daten auch weitergegeben werden?
gruss
Zuletzt geändert von debianfan am 11.06.2018 11:33, insgesamt 1-mal geändert.
Ich weiß viel - aber nicht alles - deswegen lerne ich gern dazu & bin für Hinweise von erfahrenen ITlern immer dankbar.
Dynpros und da besonders die Tabellen arbeiten mit einer Übertragung der Daten per Name in Datenfelder.
Die Anweisung LOOP AT der Dynpro-Ablauflogik macht dabei nichts anderes als das alle sichtbaren Felder des Table-Controls (bzw. Steploops) Zeile für Zeile in die entsprechende Struktur bzw. Felder des Hauptprogramms kopiert werden. Damit diese im Anschluss dann in den richtigen Tabellenzeilen landen muss man das Einfügen (MODIFY) unter Umständen selbst machen. Das Problem ist hierbei die TOP_LINE, also die Position der ersten Zeile im Table-Control relativ zur Position in der Datentabelle (Position des Scrolbalkens).
Ich bin mir jetzt nicht sicher, wenn man eine Tabelle mit Kopfzeile verwendet, ob der Standard die Übertragung vom Dynpro in diese Tabelle auch automatisch durchführen kann. Ich hab mir hierfür vor Jahren eine eigene Klasse geschrieben welche die Übertragung durchführt und mir seither keine Gedanken mehr darüber gemacht und dadurch auch schlicht vergessen was out-of-the-box geht und was nicht.
Schau mal nach ob zwischen LOOP und ENDLOOP in der Dynpro-Ablauflogik PAI-Module aufgerufen werden und was da drinnen genau gemacht wird.
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.