Dynpro "INPUT" konnte nicht interpretiert werden

Getting started ... Alles für einen gelungenen Start.
7 Beiträge • Seite 1 von 1
7 Beiträge Seite 1 von 1

Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von beterman (ForumUser / 51 / 2 / 0 ) »
Hallo zusammen,
ich versuche gerade dabei ein einfaches Dynpro Report zu programmieren. Mein Programm besteht aus zwei Fenstern. Für erste Fenster (Dynpro 0100) bin ich gerade dabei Programm Ablauflogik zu programmieren aber kriege ständig unten stehende Fehlermeldung. Wo kann das Problem liegen?

Bild

In vielen Büchern gibt es Beispiele diesbezüglich.

Code: Alles auswählen.

module USER_COMMAND_0100 input.
sollte richtig sein. Ich verstehe immer noch nich, wo ich Fehler mache. Hat jemand vielleicht eine Lösung oder Erklärung?
Vielen Dank im Voraus
Gruß
Basay

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von Frank Dittrich (Expert / 674 / 0 / 15 ) »
Du solltest den in der Dynpro-Ablauflogik verwendeten MODULE nicht in der Dynpro-Ablauflogik implementieren, sondern in einem ABAP-Quelltext.

Wenn Du den Quelltext ab MODULE USER_COMMAND_0100 INPUT aus der Dynpro-Ablauflogik löschst und auf den MODULE-Namen in der MODULE-Anweisung doppelklickst, navigierst Du zu der MODULE-Anweisung im ABAP-Quelltext.
Wenn es im ABAP-Quelltext noch keinen solchen MODULE gibt, wirst Du von System gefragt, ob und in welchem Include Du diesen anlegen möchtest...

Frank

Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von beterman (ForumUser / 51 / 2 / 0 ) »
Hallo Frank
Danke für schnelle Antwort. Ich hatte vorher genau so gemacht, wie du beschrieben hast. Mein Programmablauf funktionierte aber nicht richtig. Deswegen habe ich entschieden, wie oben zu programmieren. In vielen Büchern gibt es Beispiele wie oben. Also MODULE werden in der Dynopro-Ablauflogik implementiert. Es irritiert mich.

Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
hi
beterman hat geschrieben:In vielen Büchern gibt es Beispiele wie oben. Also MODULE werden in der Dynopro-Ablauflogik implementiert. Es irritiert mich.
Ja, mich auch! Das ist das erste mal, dass ich davon gehört habe :shock:
Ne, ernsthaft: In der Dynpro-Ablauflogik sind nur bestimmte Anweisungen (PROCESS... FIELD... CALL... MODULE...) erlaubt und die Module selbst müssen im Quellcode des aufrufenden Programms definiert werden.
Die Beispiele in den Büchern werden meistens oft aus Platzgründen zusammengeschrieben, aber wie auch schon Frank bemerkt hat, ist das nicht richtig.
beterman hat geschrieben:Ich hatte vorher genau so gemacht, wie du beschrieben hast. Mein Programmablauf funktionierte aber nicht richtig.
Was hat nicht richtig funktioniert? Vielleicht können wir dir hier bei diesem Problem weiterhelfen.

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

Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von Frank Dittrich (Expert / 674 / 0 / 15 ) »
beterman hat geschrieben:Ich hatte vorher genau so gemacht, wie du beschrieben hast. Mein Programmablauf funktionierte aber nicht richtig.
Dann hättest Du den Fehler suchen müssen.
Wenn der Programmablauf "nicht richtig" funktionierte, klingt das ja so, als ob das Dynpro zumindest prozessiert werden konnte, auch wenn nicht das passiert ist, was Du wolltest.
Da hättest Du z.B. mal den Debugger nutzen können um heruaszufinden, was da schief geht.

Eventuell hast Du den Beispiel-Code ja nicht vollständig übernommen.

Denn die Anweisung

Code: Alles auswählen.

IF sy-subrc <> 0.
ist an der Stelle nicht sinnvoll.
Die erste Anweisung innerhalb des PAI-Modules user_command_100 ist eine IF-Anweisung, die den Inhalt von SY-SUBRC nicht ändert.

Also wertet die zweite IF-Anweisung den Wert von SY-SUBRC aus, der irgendwo außerhalb des Modules durch eine Anweisung gesetzt wurde.

Sinnvoll wird die IF-Anweisung erst dann, wenn z.B. statt der Kommentarzeile davor tatsächlich ein Sperr-Funktionsbaustein aufgerufen wird, der bei einem Fehler SY-SUBRC setzt.

Welcher Fehler tatsächlich dazu geführt hat, dass sich das Programm anders verhielt als von Dir erwartet, lässt sich angesichts des kurzen Quelltextausschnitts aber nicht sagen.

Falls Du für weitere Fragen hier Quelltextausschnitte postest, dann lieber nicht als Screenshot, sondern unter Nutzung der code-Tags als Text.
Dann erleichterst Du nämlich anderen die Arbeit, die Dir antworten und dabei auf Quelltext-Ausschnitte Bezug nehmen wollen.
Deswegen habe ich entschieden, wie oben zu programmieren. In vielen Büchern gibt es Beispiele wie oben. Also MODULE werden in der Dynopro-Ablauflogik implementiert. Es irritiert mich.
Also ich habe ja schon einige Bücher gelesen.
Dass in einem stünde, die Modul-Implentierung würde in die Dynpro-Ablauflogik gehören, das ist mir noch nie aufgefallen.
Welches Buch soll denn das sein?
Es kann aber sein, dass einfach der Quelltext der Dynpro-Ablauflogik und der ABAP-Quelltext nacheinander abgedruckt wurden (hoffentlich mit ein paar Leerzeilen dazwischen).
Und wenn man weiß, dass ABAP-Anweisungen nicht in die Dynpro-Ablauflogik gehören, dann kommt man beim Lesen vielleicht gar nicht auf die Idee, dass das für Neulinge nicht eindeutig ist.

Die Kommentarzeilen vor der fraglichen MODULE-Anweisung sehen aber ganz wie die beim Anlegen eines Includes automatisch generierten Kommentarzeilen aus. Daher kann ich die Idee auch nicht ganz nachvollziehen, das in der Dynpro-Ablauflogik unterbringen zu wollen.

Noch ein Tipp:
Sowohl in der Dynpro-Ablauflogik als auch im ABAP-Quelltext bekommt man die Dokumentation zur Syntax einer Anweisung hoch, wenn man den Cursor auf ein Schlüsselwort wie MODULE oder LOOP stellt und dann F1 drückt.
Dann könnte einem auch auffallen, dass die MODULE-Anweisung in der Dynpro-Ablauflogik eine andere Bedeutung und andere Syntax-Bestandteile hat als die MODULE-Anweisung in einem ABAP-QUelltext.

Frank

Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von beterman (ForumUser / 51 / 2 / 0 ) »
Hi Frank, Hi ADT :-)

vielen Dank nochmals für ihre Antworten. Ich bin seit langem über dieses Thema beschäftigt und kann leider kein richtigen Weg finden.
Meine Aufgabe besteht darin ein DynPro Programm zu schreiben, das aus 2 Fenster bestehen muss. Diese zwei Fenstern wurden durch Painter schon "designet".

Bevor ich die Codes hier abschreibe, wollte ich ganz kurz, wie ich mein Programm ablaufen sollte.

Es ist mein erstes Fenster, wo man was eingeben muss.

Bild

Benutzer muss hier die Unternehmen bzw. Reisenummer in entsprechenden Feldern eingeben. Diese beide Nummern werden von der Tabelle ZZ09_WS12_TAB31B gelesen.
Durch Eingabe-Taste müssen die Flüge mit entsprechenden Reisenummer und Gruppenummer von der Tabelle ZZ09_WS12_TAB31B gelesen und unten im Container angezeigt werden. Es wird wahrscheinlich mehrere Flüge mit dieser Reisenummer angezeigt werden. Benutzer muss in der Lage sein, durch double Klick den Reise zu ändern. (Hier kommt das zweite Fenster ins Spiel)

Bild

In zweitem Fenster werden die detaillierten Informationen über die Reise anzeigt. Benutzer kann diese Reise Buchen oder Stornieren. (Es ist nicht die Aufgabe, was ich machen soll.) Hier ist wichtig: Mit Zurück kann Benutzer das erste Fenster zurück gehen.

Was mir schief geht, dass in erstem Fenster durch Enter das Programm ohne die Informationen unten anzuzeigen direkt zweite Fenster gesprungen wird. Und in zweitem Fenster springt man immer auf das erste Fenster, egal man welche Taste gedrückt hat. (Buchen, Stornieren oder Zurück)

Ich habe bis jetzt folgendes programmiert.

Hier ist die Code Abschnitt für Hauptprogramm.

Code: Alles auswählen.

REPORT  ZZ09_WS12_PRKT_4.

TABLES ZZ09_WS12_TAB31A.
TABLES ZZ09_WS12_TAB31B. * relevante Tabelle für Reiseinformationen

DATA ok_code TYPE sy-ucomm.

*ALV-Grid List
DATA: gs_layout TYPE lvc_s_layo,
      refcont1 TYPE REF TO cl_gui_custom_container,
      refgrid TYPE REF TO cl_gui_alv_grid.
* Interne Tabelle
DATA:
      it_reisen TYPE STANDARD TABLE OF ZZ09_WS12_TAB31B.
* Struktur für Reisedatensatz
DATA wa_reise TYPE ZZ09_WS12_TAB31B.

CALL SCREEN '0100'.


INCLUDE ZZ09_WS12_PRKT_4_STATUS_010O03.

INCLUDE ZZ09_WS12_PRKT_4_GRIDLIST_0O03.

INCLUDE ZZ09_WS12_PRKT_4_STATUS_010O04.

INCLUDE ZZ09_WS12_PRKT_4_LOAD_DATA_O01.

INCLUDE ZZ09_WS12_PRKT_4_USER_COMMAI04.

INCLUDE ZZ09_WS12_PRKT_4_USER_COMMAI05.

INCLUDE ZZ09_WS12_PRKT_4_EXIT_COMMAI03.
INCLUDES werden automatisch von ABAP im Hauptprogramm integriert.

und hier sind die Codes für INCLUDES...

INCLUDE ZZ09_WS12_PRKT_4_STATUS_010O03.

Code: Alles auswählen.

MODULE STATUS_0100 OUTPUT.
SET PF-STATUS '0100'.
SET TITLEBAR '0100'.

ENDMODULE.                 " STATUS_0100  OUTPUT
INCLUDE ZZ09_WS12_PRKT_4_GRIDLIST_0O03.

Code: Alles auswählen.

MODULE GRIDLIST_0100 OUTPUT.
IF refcont1 IS INITIAL.
CREATE OBJECT refcont1
EXPORTING
container_name = 'CONTAINER'.
CREATE OBJECT refgrid
EXPORTING
i_parent = refcont1.
CALL METHOD refgrid->set_table_for_first_display
EXPORTING i_structure_name = 'ZZ09_WS12_TAB31B'
is_layout = gs_layout
CHANGING it_outtab = it_reisen.
CALL METHOD refgrid->set_toolbar_interactive.
ELSE.
* Hole Daten und transfer in Interne Tabelle
IF NOT ZZ09_WS12_TAB31B-COMP IS INITIAL.
SELECT * FROM ZZ09_WS12_TAB31B INTO TABLE it_reisen WHERE comp = ZZ09_WS12_TAB31B-COMP.
ENDIF.
* Bei Änderungen muss die Tabelle aktualisiert werden
CALL METHOD refgrid->refresh_table_display.
ENDIF.
CALL METHOD cl_gui_control=>set_focus
EXPORTING
control = refgrid.
ENDMODULE.                 " GRIDLIST_0100  OUTPUT

INCLUDE ZZ09_WS12_PRKT_4_STATUS_010O04.

Code: Alles auswählen.

MODULE STATUS_0101 OUTPUT.
SET PF-STATUS '0101'.
SET TITLEBAR '0101'.

ENDMODULE.                 " STATUS_0101  OUTPUT
INCLUDE ZZ09_WS12_PRKT_4_LOAD_DATA_O01.

Code: Alles auswählen.

MODULE LOAD_DATA_0101 OUTPUT.

SELECT SINGLE * FROM ZZ09_WS12_TAB31B INTO wa_reise WHERE REISENR = ZZ09_WS12_TAB31B-REISENR.
MOVE-CORRESPONDING wa_reise TO ZZ09_WS12_TAB31B.

ENDMODULE.                 " LOAD_DATA_0101  OUTPUT
INCLUDE ZZ09_WS12_PRKT_4_USER_COMMAI04.

Code: Alles auswählen.

MODULE USER_COMMAND_0101 INPUT.

SELECT SINGLE * FROM ZZ09_WS12_TAB31B INTO wa_reise WHERE REISENR = ZZ09_WS12_TAB31B-REISENR.
IF ok_code = 'EXIT'.
SET SCREEN '0'.
ENDIF.
IF ok_code = 'BOOK' AND NOT wa_reise-STATUS = 2.
UPDATE ZZ09_WS12_TAB31B SET STATUS = 1.
ENDIF.
IF ok_code = 'CANCEL' AND wa_reise-STATUS = 1.
UPDATE ZZ09_WS12_TAB31B SET STATUS = 2.
ENDIF.
CLEAR ok_code.

ENDMODULE.                 " USER_COMMAND_0101  INPUT
INCLUDE ZZ09_WS12_PRKT_4_USER_COMMAI05.

Code: Alles auswählen.

MODULE USER_COMMAND_0100 INPUT.

* Reisedetail Steuerung
IF ok_code = 'MODIFY' AND NOT ZZ09_WS12_TAB31B-REISENR IS INITIAL.
* Transaktion sperren (Sperrobjekt)
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ELSE.
CALL SCREEN '0101' STARTING AT 10 10.
ENDIF.
ENDIF.
CLEAR ok_code.

ENDMODULE.                 " USER_COMMAND_0100  INPUT
INCLUDE ZZ09_WS12_PRKT_4_EXIT_COMMAI03.

Code: Alles auswählen.

MODULE EXIT_COMMAND_0100 INPUT.

IF ok_code = 'EXIT'.
LEAVE TO SCREEN 0.
SET SCREEN 0.
ENDIF.
CLEAR ok_code.
ENDMODULE.                 " EXIT_COMMAND_0100  INPUT
Hier ist die Eigenschaften von Dynpro 100 und Dynpro 101

Dynpro 100

Bild

Dynpro 101

Bild

Als Folgedynpro habe ich 101 für 100 und 100 für 101 eingegeben. Richtig?


Ich weiß nicht, ob es richtige weg ist, alles inkl. Codes hier abzuschreiben. Ich hoffe, dass alles für Sie einfach und klar ist.
Warum wird keine Informationen in Fenstern angezeigt und warum funktioniert die Ablauf Mechanismus nicht richtig?

Vielen Dank im Voraus

Gruß
Basay

Re: Dynpro "INPUT" konnte nicht interpretiert werden

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
hi! Ich habs jetzt nicht ausprobiert, aber ich glaube Enter aktiviert die Dynprofolge!
Stell am besten bei beiden Dynpros das Folgedynpro auf sich selbst.
Wenn du wirklich ein neues aufrufen willst mach das dann mit CALL SCREEN.

Ich hab nie mit den Dynprofolgen gearbeitet, daher weiß ich auch nicht, wie die sich bei bestimmten Funktionencodes verhalten.
Ich glaub man muss die Verarbeitung explizit mit Messages usw. abbrechen um zu verhindern, dass automatisch aufs nächste Dynpro der Folge verzweigt wird.

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

Seite 1 von 1

Vergleichbare Themen

2
Antw.
1191
Views
Excel Daten werden 2x unterschiedlich interpretiert
von SaskuAc » 22.04.2016 07:00 • Verfasst in ABAP® für Anfänger
2
Antw.
2816
Views
Beim Batch Input Dynpro-Felder auslesen
von Thomas Koßmann » 30.05.2005 15:44 • Verfasst in ABAP® Core
6
Antw.
4895
Views
Web-Dynpro: längeres Dynpro nicht sichtbar
von erzoo24 » 08.03.2017 11:33 • Verfasst in Web-Dynpro, BSP + BHTML
0
Antw.
2645
Views
4
Antw.
3387
Views
Feld aus Dynpro A an Dynpro B übergeben
von SAPAlex » 06.03.2008 17:35 • Verfasst in ABAP® für Anfänger

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141