CL_DD_DOCUMENT & CL_DD_INPUT_ELEMENT
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Hallo zusammen!
ich habe leider wieder die Dynamischen Dokumente benutzt... *seufz*
Ich stelle mit CL_DD_INPUT_ELEMENT ein Eingabefeld dar.
Allerdings muss der Anwender zwingend ENTER drücken, damit der Wert übernommen wird.
Wenn ich den VALUE Wert "einfach so" abfrage, steht immer der letzte Wert aktualisierte Wert drin, aber nicht zwingend der Wert, den der Anwender gerade eingegeben hat.
Hat jemand eine Idee, wie ich das lösen kann?
Danke und Gruß
Enno
ich habe leider wieder die Dynamischen Dokumente benutzt... *seufz*
Ich stelle mit CL_DD_INPUT_ELEMENT ein Eingabefeld dar.
Allerdings muss der Anwender zwingend ENTER drücken, damit der Wert übernommen wird.
Wenn ich den VALUE Wert "einfach so" abfrage, steht immer der letzte Wert aktualisierte Wert drin, aber nicht zwingend der Wert, den der Anwender gerade eingegeben hat.
Hat jemand eine Idee, wie ich das lösen kann?
Danke und Gruß
Enno
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 / 4414 / 224 /
1186
)
»
Stellst du das Ganze in einem HTML-Viewer im SAPgui dar?
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
Nein. Das ist ein eigenes Control. aber wahrscheinlich wird der gleiche HTML-Viewer verwendet.
Siehe Demoprogramm DD_ADD_FORM_INPUT.
Siehe Demoprogramm DD_ADD_FORM_INPUT.
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Ich nehme mal an, du willst den Wert in einem PAI/PBO Lauf (Druck auf Button oder ähnliches) "außerhalb" der Verarbeitung durch die DD-Klassen bekommen, oder?
Bei meiner Lösung dafür verwende ich zwar nicht das CL_DD_DOCUMENT sondern eine eigene HTML-Generierung (die nicht so unschönen HTML-Code produziert) aber ich sehe jetzt grundsätzlich kein Problem, dass das nicht auch mit CL_DD_DOCUMENT gehen sollte.
Das Formular muss dazu ein "verstecktes" Feld für den Funktionscode beinhalten und dann muss man dem HTML_VIEWER (der ja zum Glück PUBLIC ist) "nur" ein Script mittels SET_SCRIPT_ON_ABAP_COMPLETED unterschieben, das bewirkt dass das Formular mit "submit" abgeschickt wird.
Der Ablauf ist ungefähr so:
1) PAI-Verarbeitung wird vom GUI aufgerufen
2) SET_SCRIPT_ON_ABAP_COMPLETED mit Übergabe des Funktionscodes und einem Timeout (500ms haben sich bewährt) für das verzögerte Auslösen des SUBMIT.
3) PAI-Verarbeitung abbrechen
4) Event-Verarbeitung wird vom Control aufgerufen
5) Den Funktionscode aus dem versteckten Feld auslesen und entsprechend verarbeiten.
Die Methode SET_SCRIPT_ON_ABAP_COMPLETED ist zwar jetzt protected, lässt sich aber mit einem einfachen Kniff auch Public aufrufen:
1) Eigene Klasse von HTML-Viewer ableiten
2) PUBLIC STATIC Methode mit Übergabe der HTML-Viewer Instanz
3) Aufruf von SET_SCRIPT_ON_ABAP_COMPLETED der übergebenen Instanz.
Einzig, wie man an die Rückgabe des HTML-Event rankommt um dann den Funktionscode weiterverarbeiten zu können, weiß ich jetzt leider nicht, weil ich mich, wie gesagt, mit CL_DD_DOCUMENT nicht so auskenne.
lg ADT
Bei meiner Lösung dafür verwende ich zwar nicht das CL_DD_DOCUMENT sondern eine eigene HTML-Generierung (die nicht so unschönen HTML-Code produziert) aber ich sehe jetzt grundsätzlich kein Problem, dass das nicht auch mit CL_DD_DOCUMENT gehen sollte.
Das Formular muss dazu ein "verstecktes" Feld für den Funktionscode beinhalten und dann muss man dem HTML_VIEWER (der ja zum Glück PUBLIC ist) "nur" ein Script mittels SET_SCRIPT_ON_ABAP_COMPLETED unterschieben, das bewirkt dass das Formular mit "submit" abgeschickt wird.
Der Ablauf ist ungefähr so:
1) PAI-Verarbeitung wird vom GUI aufgerufen
2) SET_SCRIPT_ON_ABAP_COMPLETED mit Übergabe des Funktionscodes und einem Timeout (500ms haben sich bewährt) für das verzögerte Auslösen des SUBMIT.
3) PAI-Verarbeitung abbrechen
4) Event-Verarbeitung wird vom Control aufgerufen
5) Den Funktionscode aus dem versteckten Feld auslesen und entsprechend verarbeiten.
Die Methode SET_SCRIPT_ON_ABAP_COMPLETED ist zwar jetzt protected, lässt sich aber mit einem einfachen Kniff auch Public aufrufen:
1) Eigene Klasse von HTML-Viewer ableiten
2) PUBLIC STATIC Methode mit Übergabe der HTML-Viewer Instanz
3) Aufruf von SET_SCRIPT_ON_ABAP_COMPLETED der übergebenen Instanz.
Einzig, wie man an die Rückgabe des HTML-Event rankommt um dann den Funktionscode weiterverarbeiten zu können, weiß ich jetzt leider nicht, weil ich mich, wie gesagt, mit CL_DD_DOCUMENT nicht so auskenne.
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
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
Danke für deinen Lösungsvorschlag ADT! das schaue ich mir mal genauer an.
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Moin Enno,
du hast das Hauptdokument vom Typ cl_dd_document. Das hat ein (öffentliches) Attribut html_control, welches auf den HTML-Viewer zeigt.
Desweiteren hast du ein Eingabefeld? vom Typ cl_dd_input_element, dessen Wert du zurück erhalten willst.
Folgende Klasse sollte dir das zurückliefern.
Ist nicht sonderlich schön und musst du aber noch ein wenig aufhübschen. Aber das sollte es tun.
Aufruf dann mittels
du hast das Hauptdokument vom Typ cl_dd_document. Das hat ein (öffentliches) Attribut html_control, welches auf den HTML-Viewer zeigt.
Desweiteren hast du ein Eingabefeld? vom Typ cl_dd_input_element, dessen Wert du zurück erhalten willst.
Folgende Klasse sollte dir das zurückliefern.
Code: Alles auswählen.
CLASS lcl_dd_helper DEFINITION INHERITING FROM cl_gui_html_viewer.
PUBLIC SECTION.
CLASS-METHODS:
test IMPORTING io_viewer TYPE REF TO cl_gui_html_viewer
iv_element_id TYPE sdydo_element_name
RETURNING VALUE(rv_data) TYPE string,
handle_sapevent FOR EVENT sapevent OF cl_gui_html_viewer IMPORTING postdata.
PRIVATE SECTION.
CLASS-DATA: mt_postdata TYPE cnht_post_data_tab.
ENDCLASS.
CLASS lcl_dd_helper IMPLEMENTATION.
METHOD test.
DATA: lt_source TYPE tsfxsftag,
lv_postdata TYPE string.
APPEND ' function test() { ' TO lt_source.
* APPEND ' window.alert(window.frames[0].document.forms[0].name); ' TO lt_source.
APPEND ' window.frames[0].document.forms[0].submit( ); ' TO lt_source.
* APPEND ' window.alert("window.alert ");' TO lt_source.
APPEND ' }' TO lt_source.
APPEND ' window.test( );' TO lt_source.
io_viewer->set_script( script = lt_source[] ).
io_viewer->execute_script( ).
SET HANDLER handle_sapevent FOR io_viewer ACTIVATION 'X'.
io_viewer->dispatch( eventid = cl_gui_html_viewer=>m_id_sapevent
cargo = space
is_shellevent = space
).
SET HANDLER handle_sapevent FOR io_viewer ACTIVATION ' '.
LOOP AT mt_postdata ASSIGNING FIELD-SYMBOL(<lv_postdata>).
lv_postdata = |{ lv_postdata }{ <lv_postdata> }|.
ENDLOOP.
SPLIT lv_postdata AT '&' INTO TABLE DATA(lt_postdata).
LOOP AT lt_postdata ASSIGNING FIELD-SYMBOL(<ls_postdata_element>).
SPLIT <ls_postdata_element> AT '=' INTO DATA(lv_element) DATA(lv_cargo).
IF lv_element = iv_element_id.
rv_data = lv_cargo.
RETURN.
ENDIF.
ENDLOOP.
ENDMETHOD.
METHOD handle_sapevent.
mt_postdata = postdata.
ENDMETHOD.
ENDCLASS.Aufruf dann mittels
Code: Alles auswählen.
data(lv_element_data) = lcl_dd_helper=>test( io_viewer = dd_document->html_control
iv_element_id = input_dd_element->id )Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
ewx
Danke Stefan! Wird ausprobiert!!
Die Idee eines Kollegen war, in den Quelltext irgendwie ein onchange in das Inputfeld einzuschmuggeln und es auch auf das onEntered Ereignis umzuleiten.
Die Idee eines Kollegen war, in den Quelltext irgendwie ein onchange in das Inputfeld einzuschmuggeln und es auch auf das onEntered Ereignis umzuleiten.
puh. wie bekomme ich denn das input Feld in meinem DOM zu fassen?black_adept hat geschrieben: ↑28.09.2021 15:03Code: Alles auswählen.
APPEND ' window.frames[0].document.forms[0].submit( ); ' TO lt_source.
ich habe noch eine Tabelle und irgendwas dazwischen...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
so geht's:
Blöd nur, weil die ID's generiert werden. das heißt, sobald ein neues Eingabefeld davor kommt, funktioniert es wahrscheinlich nicht mehr... :(
Code: Alles auswählen.
window.frames[0].document.A1T2C2F2.submit( );
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Moin Enno,
probier mal "mein" ungeändertes Coding und setze einen Breakpoint dahin, wo der POST-Request eingesammelt wird. M.E. sollten dort die Werte für ALLE Variablen der FORM drin stehen und wenn du ein DD-Eingabefeld hat kannst du den Wert über dessen ID abfragen ( die ID ist ein public Attribut der DD-Eingabefeldklasse ) .
Daher auch der Aufruf mittels
probier mal "mein" ungeändertes Coding und setze einen Breakpoint dahin, wo der POST-Request eingesammelt wird. M.E. sollten dort die Werte für ALLE Variablen der FORM drin stehen und wenn du ein DD-Eingabefeld hat kannst du den Wert über dessen ID abfragen ( die ID ist ein public Attribut der DD-Eingabefeldklasse ) .
Daher auch der Aufruf mittels
Code: Alles auswählen.
data(lv_element_data) = lcl_dd_helper=>test( io_viewer = dd_document->html_control
iv_element_id = input_dd_element->id )
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Im Endeffekt schlagen hier ja eh alle dasselbe vor:
Das (interne) Formular abschicken um an die Daten ranzukommen. 😉
Ich möchte hier noch kurz einwerfen (vielleicht auch für Neueinsteiger die das später mal Lesen), dass man ja auf das Event vom HTML-Control "warten" muss. Da das den PAI/PBO Lauf "unterbricht" muss man eine Möglichkeit schaffen wie man die angestrebte Funktions(code)verarbeitung "nach" die Eventverarbeitung bekommt:
Möglichkeit 1)
Wie schon von mir vorhin erwähnt, man überträgt den ausgelösten Funktionscode gleichzeitig mit dem Script für das SUBMIT in ein Formularfeld. Somit wird dieser auch direkt im HTML-Event zur Verfügung gestellt.
Möglichkeit 2)
Eine (globale) Variable verwenden, um den ausgelösten Funktionscode zu speichern. Der Nachteil hier ist m.E., dass man Gefahr läuft die falsche Funktions aufzurufen, wenn man darauf vergisst die Variable zu löschen usw.
Eine kleine Anmerkung noch zur Lösung von black_adept:
SET_SCRIPT_ON_ABAP_COMPLETE ist meiner Meinung nach dem SET_SCRIPT vorzuziehen, weil es etwas verzögert ausgelöst wird, sodass dem HTML-Control auf der Client-seite etwas mehr Zeit für den Aufbau der Seite bleibt. Wenn ,man so wie ich oft auch noch JQuery oder ähnliches im HTML-Teil einsetzt, ist meistens auch noch ein Timeout vor dem eigentlichen SUBMIT notwendig, damit die API auch genug Zeit hatte alles zu "initialisieren".
lg ADT
Das (interne) Formular abschicken um an die Daten ranzukommen. 😉
Ich möchte hier noch kurz einwerfen (vielleicht auch für Neueinsteiger die das später mal Lesen), dass man ja auf das Event vom HTML-Control "warten" muss. Da das den PAI/PBO Lauf "unterbricht" muss man eine Möglichkeit schaffen wie man die angestrebte Funktions(code)verarbeitung "nach" die Eventverarbeitung bekommt:
Möglichkeit 1)
Wie schon von mir vorhin erwähnt, man überträgt den ausgelösten Funktionscode gleichzeitig mit dem Script für das SUBMIT in ein Formularfeld. Somit wird dieser auch direkt im HTML-Event zur Verfügung gestellt.
Möglichkeit 2)
Eine (globale) Variable verwenden, um den ausgelösten Funktionscode zu speichern. Der Nachteil hier ist m.E., dass man Gefahr läuft die falsche Funktions aufzurufen, wenn man darauf vergisst die Variable zu löschen usw.
Eine kleine Anmerkung noch zur Lösung von black_adept:
SET_SCRIPT_ON_ABAP_COMPLETE ist meiner Meinung nach dem SET_SCRIPT vorzuziehen, weil es etwas verzögert ausgelöst wird, sodass dem HTML-Control auf der Client-seite etwas mehr Zeit für den Aufbau der Seite bleibt. Wenn ,man so wie ich oft auch noch JQuery oder ähnliches im HTML-Teil einsetzt, ist meistens auch noch ein Timeout vor dem eigentlichen SUBMIT notwendig, damit die API auch genug Zeit hatte alles zu "initialisieren".
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
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
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Sehe ich anders. Die DD-Elemente bauen etwas Dynpro-ähnliches auf ( siehe SE80, der obere Bereich wo man den Namen des Objekts eingibt). D.h., dass die Seite üblicherweise statisch schon lange aufgebaut ist und der User jetzt Eingaben machen kann. Die dargestellten Daten sind dem Programm bekannt - schließlich hat es das das DD-Dokument erstellt. Aber diese Usereingaben stehen schon bei SET_SCRIPT zur Verfügung, wenn der User auf einen (Dynpro)-Button außerhalb des DD-Formulars klickt.a-dead-trousers hat geschrieben: ↑28.09.2021 19:45Eine kleine Anmerkung noch zur Lösung von black_adept:
SET_SCRIPT_ON_ABAP_COMPLETE ist meiner Meinung nach dem SET_SCRIPT vorzuziehen, weil es etwas verzögert ausgelöst wird, sodass dem HTML-Control auf der Client-seite etwas mehr Zeit für den Aufbau der Seite bleibt. Wenn ,man so wie ich oft auch noch JQuery oder ähnliches im HTML-Teil einsetzt, ist meistens auch noch ein Timeout vor dem eigentlichen SUBMIT notwendig, damit die API auch genug Zeit hatte alles zu "initialisieren".
Der HTML-Viewer führt das Script, welches mit SET_SCRIPT gesetzt wird erst mit dem DISPATCH aus. Mein Lösungsvorschlag triggert den Dispatch "falsch" an, so dass die "normale" Eventverarbeitung des HTML-Controls es nicht schafft, die POST-Daten an die DD-Objekte weiterzureichen, die sich registriert haben um einen Abgleich der Formulardaten mit den internen DD-Attributen zu schaffen, so dass diese "fremden" Eventsubscriber leer ausgehen, wohingegen. Schade eigentlich - hatte erst gedacht das damit machen zu können und damit quasi ein Flush der DD-Objekte zu erzwingen.a-dead-trousers hat geschrieben: ↑28.09.2021 19:45dass man ja auf das Event vom HTML-Control "warten" muss. Da das den PAI/PBO Lauf "unterbricht" muss man eine Möglichkeit schaffen wie man die angestrebte Funktions(code)verarbeitung "nach" die Eventverarbeitung bekommt
Da das DISPATCH des HTML-Viewers innerhalb des Lösungsvorschlags aufgerufen wird, wird der eigene Eventhandler quasi als einziger verarbeitet, muss sich aber die Formularwerte selber aus den POST-Daten zusammenklauben .
Das Coding kann somit direkt aus dem normalen ABAP-Programmfluss aufgerufen werden und verhält sich nach außen wie eine Methode, welche die Daten (synchron zum Zeitpunkt des Aufrufs ) aus dem DD-Formular abgreift.
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
okay... Jetzt verstehe ich erst was du mit dem DISPATCH machst.
Keine schlechte Idee.
Wäre dann damit Möglichkeit 3 wie man die Daten ohne Verlust der Programmablauflogik bekommt. Im Falle von CL_DD_DOCUMENT hat man damit zwar leider keinen Zugriff auf die Attribute innerhalb von CL_DD_DOCUMENT aber bei anderen Anwendungen, wo man selber "Herr im Haus" (oder besser "Herr im HTML") ist, scheint das durchaus praktisch zu sein.
Keine schlechte Idee.
Wäre dann damit Möglichkeit 3 wie man die Daten ohne Verlust der Programmablauflogik bekommt. Im Falle von CL_DD_DOCUMENT hat man damit zwar leider keinen Zugriff auf die Attribute innerhalb von CL_DD_DOCUMENT aber bei anderen Anwendungen, wo man selber "Herr im Haus" (oder besser "Herr im HTML") ist, scheint das durchaus praktisch zu sein.
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
Zwischenzeitlich erhalte ich mit dieser Variante einen CNTL_ERROR short dump... :/
umgestiegen.
Blöd hierbei: sobald ein Eingabefeld dazu kommt oder gelöscht wird, dann funktioniert das nicht mehr.
Mittelfristig werde ich wohl auf ALV-Grid als Eingabe umstellen müssen.
Bin jetzt wieder aufewx hat geschrieben: ↑28.09.2021 16:46so geht's:Blöd nur, weil die ID's generiert werden. das heißt, sobald ein neues Eingabefeld davor kommt, funktioniert es wahrscheinlich nicht mehr... :(Code: Alles auswählen.
window.frames[0].document.A1T2C2F2.submit( );
Code: Alles auswählen.
APPEND ' window.frames[0].document.forms[0].submit( ); ' TO lt_source.
Blöd hierbei: sobald ein Eingabefeld dazu kommt oder gelöscht wird, dann funktioniert das nicht mehr.
Mittelfristig werde ich wohl auf ALV-Grid als Eingabe umstellen müssen.
Seite 1 von 1
Vergleichbare Themen
18
Antw.
Antw.
11796
Views
Views
0
Antw.
Antw.
1210
Views
Views
PS - Strukturbericht Y_TE0_60000001 PSP-Element
von manuk » 01.09.2005 14:42 • Verfasst in Financials
von manuk » 01.09.2005 14:42 • Verfasst in Financials
0
Antw.
Antw.
3401
Views
Views
0
Antw.
Antw.
1475
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1507
vor 3 Tagen von a-dead-trousers 5 / 1507
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 3 Tagen von a-dead-trousers 5 / 1507
vor 3 Tagen von a-dead-trousers 5 / 1507