Einfaches Dynpro mit Programm verbinden
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.Ich brauche ein Beispiel dafür, wie ich ein einfaches Dynpro mit dem Screenpainter erstelle und dessen Daten in ein Programm überführe.
Wie ich Felder mit dem Screen Painter erstelle oder Radiobuttons gruppiere weiß ich, aber nicht wie ich die Daten vom Dynpro weiterleite und ob es richtig ist, den Dynproaufruf an den Anfang des Programms zu stellen.
Ausgangslage ist Folgende:
Ich benötige von dem User eine Auswahl mit Radiobutton, bei der er sich entscheidet ob er Daten importieren oder exportieren möchte. Außerdem muss er bei einem Import eine Zahl angeben. Diese Angaben sollen in das Programm übertragen werden, also den Report in dem die hauptsächliche Funktionalität abläuft.
Zuerst habe ich das mit Funktionsbausteinen, wie POPUP Get Value versucht, aber ich habe keine Ahnung wie ich damit einen Zahlenwert abfragen kann, ohne das er im Infotext Benutzername stehen hat. Denke das wäre alles mit Dynpro einfacher.
Trotzdem hier als Beispiel der Code für den FUBA:
Wie ich Felder mit dem Screen Painter erstelle oder Radiobuttons gruppiere weiß ich, aber nicht wie ich die Daten vom Dynpro weiterleite und ob es richtig ist, den Dynproaufruf an den Anfang des Programms zu stellen.
Ausgangslage ist Folgende:
Ich benötige von dem User eine Auswahl mit Radiobutton, bei der er sich entscheidet ob er Daten importieren oder exportieren möchte. Außerdem muss er bei einem Import eine Zahl angeben. Diese Angaben sollen in das Programm übertragen werden, also den Report in dem die hauptsächliche Funktionalität abläuft.
Zuerst habe ich das mit Funktionsbausteinen, wie POPUP Get Value versucht, aber ich habe keine Ahnung wie ich damit einen Zahlenwert abfragen kann, ohne das er im Infotext Benutzername stehen hat. Denke das wäre alles mit Dynpro einfacher.
Trotzdem hier als Beispiel der Code für den FUBA:
Code: Alles auswählen.
ls_query-tabname = 'USR01'. "Das führt anscheinend zur Anzeige "Benutzername", weiß aber nicht was ich da sonst hinschreiben muss
ls_query-fieldname = 'BNAME'.
append ls_query to lt_query.
START-OF-SELECTION.
CALL FUNCTION 'POPUP_GET_VALUES'
EXPORTING
popup_title ='Please input the exact number of your DATA.'
TABLES
fields = lt_query
EXCEPTIONS
error_in_fields = 1
others = 2.
READ TABLE lt_query INTO ls_query with key fieldname = 'BNAME'.
IF sy-subrc = 0.
write:/ ls_query-value.
ENDIF.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Daten werden zwischen Programm und Dynpro durch Namensgleichheit übertragen.
Das heißt, du kannst eine globale Variable oder eine Tabelle/ Struktur, die du mittels TABLES-Anweisung bekannt gegeben hast, im Dynpro anzeigen.
Die Werte werden aus den Eingabefeldern im PAI (Process After Input) übernommen.
Siehe Programme DEMO_DYNPRO*
Das heißt, du kannst eine globale Variable oder eine Tabelle/ Struktur, die du mittels TABLES-Anweisung bekannt gegeben hast, im Dynpro anzeigen.
Die Werte werden aus den Eingabefeldern im PAI (Process After Input) übernommen.
Siehe Programme DEMO_DYNPRO*
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Da es hier offenbar um die Grundlagen geht, würde ich hinzufügen wollen, dass Du für solch Programm nicht den Programmtyp "Ausführbares Programm" (also keinen REPORT) verwenden solltest. Ich sage das, weil viele Entwickler reflexartig für alles den REPORT-Typ verwenden, selbst für Subroutinenpools (und leider lässt ABAP ihnen das durchgehen). Es gibt zwar Möglichkeiten, auch in Reports eigene Dynpros einzuhängen, aber das ist fortgeschrittene Programmierung und sollte nicht verwendet werden, bevor man nicht mit "normalen", Dynpro-basierten Programmen Erfahrung gesammelt hat.
Was Du stattdessen machen musst, ist folgendes:
Was Du stattdessen machen musst, ist folgendes:
- Lege in der SE38 ein Programm vom Typ "Modulpool" an.
- Lege in der SE51 für das soeben angelegte Programm ein oder mehrere Dynpros an.
- Lege in der SE93 einen Transaktionscode vom Typ "Dialogtransaktion" an, der auf das Dynpro verweist, mit dem Du starten möchtest.
- Lege wieder in der SE38 globale Felder an, die den Namen der Felder tragen, die Du in Deinem Dynpro verwendest. Wie ewx schon sagte, bewirkt dies, dass die Werte dieser Felder automatisch in das und aus dem Dynpro transportiert werden.
- Lege in der SE43 einen GUI-Status an, in dem Du die möglichen Okcodes definierst. Minimal solltest Du die Abbruch-Schaltflächen (den grünen Pfeil, das rote Kreuz usw.) hier definieren, damit Du einen Okcode bekommst, mit dem Du Dein Programm zumindest mal wieder verlassen kannst. Füge Deinem PBO-Modul einen entsprechenden Befehl SET PF-STATUS hinzu.
- Lege in Deinem Dynpro ein PBO-Modul an, in dem Du notwendige Initialisierungen (Feldvorbelegungen usw.) triffst.
- Lege in Deinem Dynpro ein PAI-Modul an, in dem Du den SY-UCOMM verarbeitest. Du kannst auch eine globale Variable als OKCODE anlegen und ihren Namen in den Feldeigenschaften des Dynpros als OKCODE-Variable hinterlegen.
Folgende Benutzer bedankten sich beim Autor DeathAndPain für den Beitrag:
Looper
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Hallo Abapsocke,
was du beschreibst ist ein "Vorschaltprogramm". All das was ewx und D&P geschrieben haben solltest du ruhig berücksichtigen wenn du mal vorhast einen Modulpool zu schreiben. Aber für das was du beschreibst ist das völlig oversized.
Bau dir einen ganz normalen Report der de facto nur aus einem Selektionsbild besteht ( Siehe Doku zu PARAMETERS, PARAMETERS ... CHECKBOX oder PARAMETERS ... RADIOBUTTON GROUP ). Dann kannst du dir den gesamten Feldtransport schenken, weil SAP dir die Daten einfach in den Parameterfeldern zurück gibt und du dann einfach im Programmcoding ein "SUBMIT" auf das eigentliche Programm machen kannst
@D&P "Fortgeschrittene Programmierung bei Einhängen von Dynpros in Reports"? Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben. Gibt es noch einen Grund einen Modulpool zu verwenden - diese Trennung von Modulpool und Report kommt m.W. noch aus R/2 Zeiten und ist seit R/3 eigentlich überflüssig. Und ich kann dir diverse Vorteile von Reports gegenüber Modulpools erzählen - aber umgekehrt fällt mir auf die Schnelle keiner mehr ein.
was du beschreibst ist ein "Vorschaltprogramm". All das was ewx und D&P geschrieben haben solltest du ruhig berücksichtigen wenn du mal vorhast einen Modulpool zu schreiben. Aber für das was du beschreibst ist das völlig oversized.
Bau dir einen ganz normalen Report der de facto nur aus einem Selektionsbild besteht ( Siehe Doku zu PARAMETERS, PARAMETERS ... CHECKBOX oder PARAMETERS ... RADIOBUTTON GROUP ). Dann kannst du dir den gesamten Feldtransport schenken, weil SAP dir die Daten einfach in den Parameterfeldern zurück gibt und du dann einfach im Programmcoding ein "SUBMIT" auf das eigentliche Programm machen kannst
@D&P "Fortgeschrittene Programmierung bei Einhängen von Dynpros in Reports"? Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben. Gibt es noch einen Grund einen Modulpool zu verwenden - diese Trennung von Modulpool und Report kommt m.W. noch aus R/2 Zeiten und ist seit R/3 eigentlich überflüssig. Und ich kann dir diverse Vorteile von Reports gegenüber Modulpools erzählen - aber umgekehrt fällt mir auf die Schnelle keiner mehr ein.
Mit Parameters komme ich nicht weiter, da ich diese ja immer an den Anfang stellen muss als Data, aber die Abfrage erst später kommen soll.
Ich sehe da nicht mehr klar, habe es jetzt nochmal mit Dynpro versucht, komme aber nicht weiter.
zum Code gibt es ein Dynpro mit zwei Radiobuttons. Ich möchte ganz unten einfach einen Text ausgeben, aber nach dem endmodule liest der Parser nicht mehr weiter.. Warum? Er soll das Dynpro starten, die Werte ablesen, damit ich dann damit im Programm arbeiten kann.
Ob Report oder MOdulepool oder wasauchimmer ist gerade nicht relevant. Es geht mir nur darum einmal ein Beispiel für diese einfache Kombination zu haben, um zu wissen wo das Problem liegt.
Ich will gerade nur am Ende eine Textausgabe haben, wenn der t1 Radiobutton geklickt wurde. Im Debugger sehe ich auch, dass die Werte korrekt weitergegeben werden, aber es gibt eben keine Ausgabe. Die brauche ich aber.
Ich sehe da nicht mehr klar, habe es jetzt nochmal mit Dynpro versucht, komme aber nicht weiter.
zum Code gibt es ein Dynpro mit zwei Radiobuttons. Ich möchte ganz unten einfach einen Text ausgeben, aber nach dem endmodule liest der Parser nicht mehr weiter.. Warum? Er soll das Dynpro starten, die Werte ablesen, damit ich dann damit im Programm arbeiten kann.
Ob Report oder MOdulepool oder wasauchimmer ist gerade nicht relevant. Es geht mir nur darum einmal ein Beispiel für diese einfache Kombination zu haben, um zu wissen wo das Problem liegt.
Ich will gerade nur am Ende eine Textausgabe haben, wenn der t1 Radiobutton geklickt wurde. Im Debugger sehe ich auch, dass die Werte korrekt weitergegeben werden, aber es gibt eben keine Ausgabe. Die brauche ich aber.
Code: Alles auswählen.
REPORT ZLK_DYNPROTEST.
DATA: input TYPE i,
output TYPE i,
lv_test(4) TYPE c,
t1(1) TYPE c, t2(1) TYPE c.
CALL SCREEN 6666.
MODULE init_screen_6666 output.
CLEAR input.
t1 = 'X'.
CLEAR: t2.
ENDMODULE.
MODULE user_command_6666 input.
output = input.
*IF exit NE space.
*
*LEAVE PROGRAM.
*ENDIF.
IF t1 = 'X'.
lv_test ='test'.
write:lv_test.
ENDIF.
ENDMODULE.Das sieht alles nach Kraut und Rüben aus, du kommst nicht weiter weil du das Konzept dahinter nicht verstehst. Es gibt doch diese Beispiel-Dynproprogramme, wie zum Geier heißen die nochmal? Das ist mMn der beste Einstieg.
Du kannst in einem dynpro keine Ausgabe mit WRITE erzeugen!
Probier Mal statt dessen MESSAGE 'text' Type 'i'. Um zu sehen dass die dynpro Eingabe funktioniert.
Probier Mal statt dessen MESSAGE 'text' Type 'i'. Um zu sehen dass die dynpro Eingabe funktioniert.
hab es jetzt verstanden. Mein Problem lag im Grundlegenden Ablauf wie der Parser beim Lesen des Codes mit einem Dynpro vorgeht, also das er in dem Call Screen Moment abspringt und ich daher nach CALL SCREEN den Befehl einfügen müsste. Jetzt kann ich auch die anderen Informationen verwenden, um tiefer in die Thematik einzusteigen.
kann nicht wirklich nach kraut und rüben aussehen weil es fast 1 zu 1 das Beispiel aus der sap dokumentation istdeejey hat geschrieben:Das sieht alles nach Kraut und Rüben aus, du kommst nicht weiter weil du das Konzept dahinter nicht verstehst. Es gibt doch diese Beispiel-Dynproprogramme, wie zum Geier heißen die nochmal? Das ist mMn der beste Einstieg.
hab nur die namen der variablen geändert.
https://help.sap.com/doc/saphelp_nw73/7 ... ameset.htm
so wie unten läufts dann auch.
Code: Alles auswählen.
DATA: input TYPE i,
output TYPE i,
lv_test(4) TYPE c,
t1(1) TYPE c, t2(1) TYPE c.
CALL SCREEN 6666.
IF t1 = 'X'.
lv_test ='test'.
write:lv_test.
ENDIF.
MODULE init_screen_6666 output.
CLEAR input.
t1 = 'X'.
CLEAR: t2.
ENDMODULE.
MODULE user_command_6666 input.
output = input.
*IF exit NE space.
*
*LEAVE PROGRAM.
*ENDIF.
LEAVE SCREEN.
ENDMODULE.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Es sieht eben doch wie Kraut und Rüben aus, und zwar deshalb, weil Du mitten im PAI eines Dynpros einen WRITE-Befehl geschrieben hast, der da nicht hingehört.
Wobei, so ganz richtig ist das auch nicht. Du kannst sehr wohl im PAI eines eigenen Dynpros WRITE verwenden. Du musst vorher nur den Befehl LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN '0'. bringen.
Lies Dir die Online-Doku dazu ruhig mal durch; vielleicht kannst Du das mal brauchen.
Wenn man einige Parameter erfragen und dann eine wie auch immer geartete Liste ausgeben (oder aufgrund der eingegebenen Daten sonst irgendwas veranstalten) will, dann ist ein Report optimal. Tatsächlich sind das die meisten Anwendungsfälle, so dass auch ich nur noch sehr selten einen Modulpool baue. Aber in dem Moment, in dem Du z.B. eine Pflegetransaktion für etwas baust, ist ein Report Mist. Versuch mal, eine MM01/MM02 als Report zu bauen! Ganz zu schweigen von einer SE80. Das wird auf jeden Fall eine Vergewaltigung des Reportkonzeptes. Erst recht wenn das Programm komplexer ist und man in Unter-Dynpros verzweigen muss.
Wobei, so ganz richtig ist das auch nicht. Du kannst sehr wohl im PAI eines eigenen Dynpros WRITE verwenden. Du musst vorher nur den Befehl LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN '0'. bringen.
Lies Dir die Online-Doku dazu ruhig mal durch; vielleicht kannst Du das mal brauchen.Und ein "Vorschaltprogramm" ist was? Letztlich entnehme ich Deinen Worten, dass Du das Selektionsbild des Reports selbst als "Vorschaltprogramm" verstehst, was man sicherlich vertreten kann. Nur hat er ja deutlich gemacht, dass ihm genau das eben nicht reicht und dass er da eine erweiterte, flexible Programmsteuerung haben möchte. Und in dem Moment, in dem das so ist, ist ein Report mit seiner einfachen Selektionsbild -> Ergebnisliste-Struktur nicht mehr ausreichend, sondern dann braucht man eine flexible Programmablaufsteuerung. Die einzige Alternative wäre, über FUNCTION KEY Schaltflächen in das Selektionsbild einzubauen und bei deren Nutzung dann aus dem entsprechenden AT SELECTION-SCREEN-Block einen CALL SCREEN auszuführen.black_adept hat geschrieben:was du beschreibst ist ein "Vorschaltprogramm".
Würde gerne mal wissen, wie das aussehen soll. Ein Report generiert Dir aus Deinem Selektionsbild ein Dynpro 1000. Bei Abfahrt geht es in das Ergebnisbild. Viel mehr kann ein Report nicht. Vielleicht kannst Du den Ablauf umbiegen, indem Du im Ereignis START-OF-SELECTION dann plötzlich andere Dynpros per CALL SCREEN rufst, aber das kommt mir wie eine üble Vergewaltigung des REPORT-Konzeptes vor. Ich sehe auch keine Vorteile; im Gegenteil bist Du bei der Gestaltung Deines Selektionsbildes auf die Möglichkeiten beschränkt, die die Report-Programmierung Dir bietet, anstatt Dein Einstiegsdynpro komfortabel per WYSIWYG zu erstellen und dabei alle Möglichkeiten offen zu haben. Allein das Gekrampfe, dass PARAMETERS-Feldnamen nur maximal 8 Zeichen lang sein dürfen, was aussagekräftige Feldnamen zunichte macht, oder dass die Selektionstexte auch auf eine oft unzureichend kurze Länge beschränkt sind, die man sich aufwendig durch die kalte Küche erweitern muss, indem man einen SELECTION-SCREEN BEGIN/END OF LINE-Block baut und dann ein Textsymbol anstelle des normalen Selektionstextes für den Parameter verwendet...Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben.
Wenn man einige Parameter erfragen und dann eine wie auch immer geartete Liste ausgeben (oder aufgrund der eingegebenen Daten sonst irgendwas veranstalten) will, dann ist ein Report optimal. Tatsächlich sind das die meisten Anwendungsfälle, so dass auch ich nur noch sehr selten einen Modulpool baue. Aber in dem Moment, in dem Du z.B. eine Pflegetransaktion für etwas baust, ist ein Report Mist. Versuch mal, eine MM01/MM02 als Report zu bauen! Ganz zu schweigen von einer SE80. Das wird auf jeden Fall eine Vergewaltigung des Reportkonzeptes. Erst recht wenn das Programm komplexer ist und man in Unter-Dynpros verzweigen muss.
Das ist eine ganz normale Vorgehensweise. Du kommentierst das, als wäre das Zauberei...DeathAndPain hat geschrieben:Würde gerne mal wissen, wie das aussehen soll. Ein Report generiert Dir aus Deinem Selektionsbild ein Dynpro 1000. Bei Abfahrt geht es in das Ergebnisbild. Viel mehr kann ein Report nicht. Vielleicht kannst Du den Ablauf umbiegen, indem Du im Ereignis START-OF-SELECTION dann plötzlich andere Dynpros per CALL SCREEN rufst, aber das kommt mir wie eine üble Vergewaltigung des REPORT-Konzeptes vor.black_adept hat geschrieben:Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben.
Der Vorteil eines Selektionsbildes ist genau das: du kannst mit einem Befehl eine komplexe Selektion definieren (SELECT-OPTIONS). Eine Liste ist eben nicht mehr nur eine Liste, sondern ein ALV oder ein Tree oder eine Kombination. Und dafür macht man einen Call screen, der dann die Controls enthält. und wenn man dann für einen Doppelklick oder sonstwas einen anderen Screen braucht, dann wird der im Report entsprechend aufgerufen.
Beitrag
von DeathAndPain (Top Expert / 1952 / 259 /
413
)
»
Ich halte es nicht für Zauberei, sondern für eine Vergewaltigung des REPORT-Prinzips. CALL SCREEN kannste gerne im Ergebnisbild machen, wenn Du im I_CALLBACK_USER_COMMAND-Programm, das Du bei Deinem CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' angegeben hast, mit Reaktionen des Users auf die Ergebnisliste umgehst. Das mache ich auch gerne. Aber da hast Du immer noch das Grundgerüst Selektionsbild->Ergebnisliste->weiteres. In dem Moment, in dem Du keine "Ergebnisliste" brauchst, weil Dein Programm etwas anderes tut, als nach Entgegennahme von Selektionsdaten Ergebnisdaten auszugeben, passt der Report als Programmtyp nicht mehr. Reports haben da eine beachtliche Flexibilität. Z.B. kannst Du einen Korrekturreport Daten verändern lassen, und die "Ergebnisliste" ist dann halt das Log. Aber sobald es darum geht, Daten einzupflegen statt rauszuholen, passt dieses Gerüst in aller Regel nicht mehr.Das ist eine ganz normale Vorgehensweise. Du kommentierst das, als wäre das Zauberei...
Wenn ich das in einem Modulpool brauche, dann mache ich einfach einen CALL SELECTION-SCREEN. Da habe ich alle Möglichkeiten des Report-Selektionsbildes, ohne die Flexibilität des Modulspools herschenken zu müssen. Brauche ich aber nur extrem selten, denn wenn ich es bräuchte, dann wäre es höchstwahrscheinlich von der Struktur her ein Report, und dann würde ich auch einen draus machen.Der Vorteil eines Selektionsbildes ist genau das: du kannst mit einem Befehl eine komplexe Selektion definieren (SELECT-OPTIONS).
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Nenn mal ein einziges Beispiel, wo ein Modulpool flexibler ist als ein ReportDeathAndPain hat geschrieben: Da habe ich alle Möglichkeiten des Report-Selektionsbildes, ohne die Flexibilität des Modulspools herschenken zu müssen
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
Aus dem 1. Posting war nicht klar, dass es das selbe Programm ist aus dem die Zusatzinformationen abgefragt werden. --> Vorschaltprogramm um die Usereingaben zu holen und dann dem "richtigen" Programm zu übergeben. Aber ok - der TE will was anderes.DeathAndPain hat geschrieben:Und ein "Vorschaltprogramm" ist was? Letztlich entnehme ich Deinen Worten, dass Du das Selektionsbild des Reports selbst als "Vorschaltprogramm" verstehst, was man sicherlich vertreten kann. Nur hat er ja deutlich gemacht, dass ihm genau das eben nicht reicht und dass er da eine erweiterte, flexible Programmsteuerung haben möchte.black_adept hat geschrieben:was du beschreibst ist ein "Vorschaltprogramm".
Die Aussage meines 1. Postings hingegen bleibt. Ein einfacher "CALL SELECTION SCREEN" um die Daten abzufragen ist viel einfacher als ein Dynpro dafür zu erstellen. Sieht nachher fast gleich aus - man verliert ein wenig Gestaltungsmöglichkeit und gewinnt viel Übersichtlichkeit im Programm.
Diese doch sehr vereinfachte Ansicht war vielleicht zur Jahrtausendwende mal aktuell. Heutzutage ist ein Report beileibe nicht mehr SelScreen -> Ergebnisliste. Hat Enno ja auch schon erwähnt.DeathAndPain hat geschrieben:Und in dem Moment, in dem das so ist, ist ein Report mit seiner einfachen Selektionsbild -> Ergebnisliste-Struktur nicht mehr ausreichend, sondern dann braucht man eine flexible Programmablaufsteuerung.
Ansonsten gilt: Man kann aus Modulpool in die Listverarbeitung wechseln und aus einem Report in die Dynprologik. Die Trennung ist somit ein Relikt aus dem Ursumpf des ABAP. Und wie gesagt - ich kenne keinen Vorteil den Programmtyp "Modulpool" zu verwenden. Es gibt nur diverse Mysteriösitäten mit einigen Zeitpunkten, wenn man in einem "echten" Modulpool via CALL SELECTION-SCREEN in die Report-Variante wechselt - umgekehrt hingegen nicht. Und ich möchte wetten, dass du mir nichts nennen kannst, das nur mit einem "echten" Modulpool geht was nicht nahezu genau so einfach mittels Report gemacht werden könnte.
Nichts für ungut, aber das kommt ziemlich weit vom Thema ab. Mir persönlich hätte es sehr geholfen wenn der Tipp gekommen wäre, dass ein Dynproaufruf, also das Call Screen im Prinzip ein Absprungpunkt ist, der Parser also nicht von oben nach unten liest, sondern in dem Moment in die Programmlogik des Dynpros springt, dort BPO und dann PAI durchführt und dann wieder in die Lücke nach Call Screen springt. Die weiterführenden Infos sind nett und etwas mit dem ich mich bei Gelegenheit eingehender beschäftigen werde, halfen mir aber nicht direkt.
Ich stehe allerdings bei einer Frage die sich mir bei den Antworten nicht so ganz erschließt:
Wie gehe ich vor:
Ich weiß nun wie ich das, was ich haben möchte mit einem Dynpro hinbekomme, aber das scheint mir nach den Aussagen mancher wohl etwas überfrachtet zu sein, also wie besser?
Ich brauche einen Userinput am Anfang, also die Wahl ob der User etwas Importieren oder Exportieren will und sollte er Importieren wollen, muss der User danach aufgefordert werden ein Value einzugeben.
Wenn ich das habe, wäre mein Problem gelöst.
Es hieß, man könne das alles auch mit Params machen, nur wie?
Ich kenne die Parametereingabe so, dass ich die Variable direkt am Anfang deklarieren muss und habe alternativ die Möglichkeit gefunden mit Get Value und Co Daten vom Nutzer abzufragen, also in Form von Funktionsbausteinen.
Ich werde gezielt noch einmal nach den verschiedenen Möglichkeiten des Userinputs suchen, wenn aber jemand ein schnelles Beispiel dafür parat hat, wäre das sehr hilfreich.
Ich stehe allerdings bei einer Frage die sich mir bei den Antworten nicht so ganz erschließt:
Wie gehe ich vor:
Ich weiß nun wie ich das, was ich haben möchte mit einem Dynpro hinbekomme, aber das scheint mir nach den Aussagen mancher wohl etwas überfrachtet zu sein, also wie besser?
Ich brauche einen Userinput am Anfang, also die Wahl ob der User etwas Importieren oder Exportieren will und sollte er Importieren wollen, muss der User danach aufgefordert werden ein Value einzugeben.
Wenn ich das habe, wäre mein Problem gelöst.
Es hieß, man könne das alles auch mit Params machen, nur wie?
Ich kenne die Parametereingabe so, dass ich die Variable direkt am Anfang deklarieren muss und habe alternativ die Möglichkeit gefunden mit Get Value und Co Daten vom Nutzer abzufragen, also in Form von Funktionsbausteinen.
Ich werde gezielt noch einmal nach den verschiedenen Möglichkeiten des Userinputs suchen, wenn aber jemand ein schnelles Beispiel dafür parat hat, wäre das sehr hilfreich.
Vergleichbare Themen
3
Antw.
Antw.
3423
Views
Views
9
Antw.
Antw.
1188
Views
Views
ABAP-Programm mit GUI-Status und Dynpro herunterladen
von L0w-RiDer » 25.11.2022 12:33 • Verfasst in ABAP® für Anfänger
von L0w-RiDer » 25.11.2022 12:33 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
872
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.