DSPF Felddefinitionen auslesen

[volkerK]

Hallo,

um eine BedienerFührung (F4) zu ermöglichen habe ich ein Programm welches den Feldnamen (bekomme ich über RTNCSRLCN) erhält und dann die möglichen werte (abhängig vom Feldnamen) zeigt.

Nun würde ich in diesem Programm gerne noch wissen ob es überhaupt möglich ist in diesem Feld eingaben zu machen (DSPATR(PR)) wie komme ich an diese Info ? steht das in der INFDS ? (ich habs darin nicht gefunden)

Vielen Dank für die Hilfe.

Volker.

[Pikachu]

Vielleicht über die Retrieve Display File Description (QDFRTVFD) API ...

[Fuerchau]

Man kann auch mit Kanonen auf Spatzen schießen.
Das Problem ist doch, dass das Attribut zur Laufzeit ein/ausgeschaltet werden kann. Und diesen Zustand kann man nicht per API herausfinden.
Ein Programm weiß über seine Eingabefelder doch Bescheid, sonst kann man ja sowieso keine Daten eingeben bzw. prüfen lassen.
Also mach einen simplen
Select;
when CSRFeld = 'Feld1';
PromptF4(...);
when ...
endsl;
Ebenso kannst du dann auch abfragen, ob die Bezugszahl für PR ein/aus ist.
Eine allgemeine Methode gibts dafür nicht, dafür ist RPGLE zu unflexibel.
Das API (sieh dir alleine mal die komplexe Struktur an) ist eben viel zu komplex.

Ich kenne auch Programme, die diese Definitionen per Ladezeittabelle erstellen und per Lookup die benötigte Prompt-Funktion aufrufen.

[volkerK]

Hallo,

an PIKACHU: werde mir die API mal anschauen.
an FUERCHAU: ich wollte das Programm mit der DSPF eben so wenig wie möglich belasten. Werde es aber wahrscheinlich doch so machen.

Nach dem verlassen der BedienerFührung muss ich im RPG ja sowieso das füllen der Felder Codieren, oder kann man das Variabel machen also kann ich irgendwie den:

Select;
when CSRFeld = 'Feld1';
eval Feld1 = BedFührungsWert;
when ...
endsl;

durch eine variable Lösung ersetzen ?

Vielen Dank

Volker.

[Fuerchau]

Im Prinzip Jein:
Das Problem ist ja, dass du in RPG nicht mit variablen Felddefinitionen umgehen kannst.
Im RPG/LE sind die Felder einer Datei wahllos im Programm gestreut, es sei denn, die definierst eine DS des Formates.
Dies funktioniert aber nur qualified, wenn das selbe Feld in der DSPF in verschiedenen Formaten vorkommt. Dann müsstest du über das API die relativen Adressen und die Länge ermitteln um dann ein Pointer-Array relative zur DS mit der Länge aufzubauen.
Dann kannst du mit einem generischen %Subst() auf die Inhalte zugreifen.
Zu bedenken ist jedoch, dass ein Format aus 2 DS'n besteht, denn das Ausgabeformat weicht vom Eingabeformat ja ab, was ein qualified dann benötigt.
Durch qualified ist das also zu regeln aber du kannst kein EXFMT mehr verwenden, da dieser ja Write/Read kombiniert. Du hast ja aber 2 Formate und musst dann auch noch die Daten dazwischen hin und her kopieren (eval-corr).
M.a.W.: wenn du es generisch machen willst, bläst du dein Programm nicht unerheblich auf.
Allerdings könntest du damit (irgendwann) ein generisches DSPF-Programm erstellen, dass dann per User-Exit (also CALL-Schnittstellen) das Ergebnis der Ein/Ausgaben irgendwie weiterleitet, so dass du dich um Bildschirmlogik nicht mehr kümmern muss.
Geklärt werden müssen nur noch Fehlerschnittstellen, Cursorsteuerungen, u.v.m.
Wenn du damit dann fertig bist, sind deine Nerven wohl eher am Ende und einen neuen Job dürftest du dir dann wohl auch suchen (müssen).

Übrigens: der alte UIM (User Interface Manager), der mit PNLGRP's arbeitet, ist so ein Programm.

[volkerK]

Hallo,

vielen Dank für die Antwort. Leider hat das bei mir aber zu viele Lücken aufgedeckt.

Wie kann ich denn für eine Format in einer DSPF eine Datenstruktur anlegen (gibt es da sowas wie LikeDS) und dann auch noch hin und her kopieren.

Entschuldige die Frage , habe es aber nicht verstanden.

Gibt es eigentlich nicht so etwas wie SendKey (strgC und strgV geht ja)

Viele Grüße und einen schönen Sonntag



Volker.

[Fuerchau]

Ja natürlich gibt es auch sowas:

D MyDsI DS likerec(MyFile.FormatName:*input)
D MyDsO DS likerec(MyFile.FormatName:*output)

Ich weis nicht, ob die DS'n dann automatisch qualified sind, wenn nicht, dann qualified anhängen.
Mittels "eval-corr MyDSI = MyDSO;" bzw. umgekehrt kann ich das übertragen.

Für die Write/Reads gibt es dann Ergänzungen:

Read MyFile MyDsI;
Write MyFile MyDsO;

Aber was die Allgemeingültigkeit angeht so ist das ja nur die halbe Wahrheit.
In RPG/LE ist das leider generell nicht möglich, da man den Formatnamen nicht in einer Variablen hinterlegen kann. Dies kann man nur in COBOL oder C++.

Hintergrund:
Jede Datei hat einen FileDescriptor mit einem Puffer.
Abhängig vom Format ist dieser Puffer zu befüllen bzw. wird dieser bereitgestellt.
Um nun die Arbeit des Programmierers zu erleichtern, hat die IBM den RPG-Compiler diesbezüglich intelligient gamacht:
Alle Variablen des Programmes haben mit dem FilePuffer absolut nichts zu tun.
Erst beim EXFMT/READ/WRITE generiert der Compiler zusätzliche Moves zwischen den Variablen und dem Filepuffer. Deshalb kann man Formatnamen nicht variabel gestalten, da der Compiler sonst nicht weiß, was er dann da tun soll.
Die COBOL-Leute haben es da etwas schwerer, da hier grundsätzlich mit dem FilePuffer native gearbeitet wird. Der Programmierer ist also selber verantwortlich, wie er mit dem Puffer umgehen muss. Dafür darf er dann aber den Formatnamen in einer Variablen ablegen.
Geschmacksache, was da nun besser ist.
Mir persönlich ist das egal, ich kann beides ganz gut.

Deine Frage nach "SendKey" verstehe ich da noch nicht. Wozu soll das gut sein?
Auch auf Windows muss ich da schon genau wissen, welches Element da den Focus gerade hat.

STRG+C/STRG+V ist eine Sache der Emulation und der Tastaturkonfiguration.
Ich kann das auch anders Konfigurieren. Manchmal geht auch:
STRG+Einfügen (Kopieren), STRG+Shift+Einfügen (Einfügen), STRG+SHIFT+Entfernen (Ausschneiden).

[volkerK]

Hallo,

vielen Dank nochmals, werde jetzt mir alles durch den Kopf gehen lassen.

Bei dem was ich bisher mit SendKeys gemacht (das war mit VBA) habe brauchte ich das Element nicht zu wissen ich bewegte mich sowiso in einem "fremden" programm, durch die "tab" taste bis ich auf dem Feld stand und gab dann meine Zeichen "ein" ohne zu wissen wie das Element hiess.

Im F04 fall wäre das dann ja sogar so dass ich ja auf dem Feld stehe und dann ja "nur" die zeichen sende. Aber sowas habe ich auf der AS400 noch nicht gesehen (wobei es bestimmt vieles gibt was ich noch nicht gesehen habe)

Viele Grüsse.

Volker.

[Fuerchau]

Auch in einem fremden Programm muss F4 auch programmiert sein sonst klappt es ja nicht.
Wer soll denn sonst entscheiden, was als Auswahl für dieses Feld gilt, wenn ich nicht weiß auf welchem Feld ich stehe?
So ganz kann ich deine Gedankengänge nicht nachvollziehen, denn es macht ja wenig Sinn, F4 als Key zu senden, wenn doch der Bediener entscheidet ob er F4 überhaupt benötigt.

[volkerK]

Hallo,
ich glaube ich habe da jetzt für Verwirrunbg gesorgt , also ich wollte natürlich nicht "F04" senden . Der Benutzer drückt die "F04" dann wird das bedienerführungsPGM gestartet und dieses PGM sendet dann , nachdem der Benutzer den entsprechenden Wert ausgewählt hat zB ein "J" und da wo der Cursor steht wird dann "J" (das ist dann genau das Feld für das die BedFührung angefordert wurde) eingefügt.

Das Beispiel mit dem fremden Programm hatte nichts mit "F04" zu tuen. Da habe ich einfach ein vorhandenes Programm gestartet und dann mit SendKeys die eingaben "simuliert", von VBA aus.

Aber egal mein jetzt Stand ist folgender:

Habe eine ds als Input und eine als Output (so wie du beschrieben hast) angelegt. Das mit dem Qualifizierten namen (MeineDatei.MeinSatzformat) ging bei uns nicht.

Dann nach dem EXFMT ein Chain ( RCDNBR Chain SFL1 DS_INPUT)

dann mit eval DS_OUTPUT = DS_INPUT (eval-corr ging auch nicht) die output ds gefüllt per %subst die entsprechende stelle geändert .

Als abschluss UPDATE SFL1 DS_OUTPUT.

so hat es funktioniert

Nun habe ich noch 2 Fragen
1.Das was bei uns nich funktioniert hat , kann das am Betriebssystem liegen?
2.Beim ersten Versuch war meine input und output DS unterschiedlich in der input DS waren nur die als eingabe oder Both in der DSPF definierten Felder in der Output waren alle. Deshalb hatte ich beim UPDATE bzw beim darauffolgenden EXFMT immer ungültige Daten.
Nun habe ich alle Felder in der DSPF als Both definiert und mittels DSPATR(PR) gesperrt (manche) normaöerweise ist das bei uns gemischt manche sind von anfang an nur als ausgabe definiert ander per Programm und PR.
Muss man das so machen oder habe ich etwas anderes falsch gemacht.?

Aber bis jetzt bin ich zufrieden , danke nochmals.


Viele Grüße
Volker.

[Fuerchau]

Da kann man mal sehen (sorry) wie weit du vom Verständnis der Variablendefinition in RPG/LE entfernt bist.
Grundsätzlich gilt hier folgendes:

Jede Variable gibt es im gesamten Programm nur ein einziges Mal.
Jede Datei (I/O/U) liefert ihre eigenen Variablendefinitionen in den automatischen I- und O-Bestimmungen.
Diese Felder sind nach ILE-Definition sog. Single-Variablen.

Nun kann man natürlich eine Datenstruktur "DS" definieren.
Ist diese DS nicht qualified, sind die enthaltenen Felder nur als Gruppe zu verstehen, die Variablen sind immer noch Single und können deshalb auch nicht in einer 2. DS definiert werden.

Mittels Qualified muss eine DS mit ihren Unterfeldern immer in der Form "XXX.YYY" angesprochen werden, was gedanklich zu einer Mehrfachdefinition führt, real aber nicht ist. XXX.YYY ist ein anderes Feld als ZZZ.YYY.

Wie funktioniert nun IO:
Jede IO-Bestimmung (Read/Write/Chain/Exfmt) ohne spezielle Angaben verwendet ausschließlich die Felder, die in den I- und O-Bestimmungen definiert sind, also i.d.R. nie die Qualified DS'n.

Verwendet man einen Lesebefehl "READ/CHAIN Datei/Format Struktur", dann muss die Struktur per Likerec(*input) definiert sein, umgekehrt bei "Write/Update Format Struktur" muss die DS mit Likerec(*output) definiert sein.

Passend dazu gibt es den "eval-Corr ZielDS = QuellDS;", der natürlich nur auf Qualified-DS funktioniert.

Nun kann man bei der Definition in den F-Bestimmungen einen Prefix "XXX." definieren, der dann auch auf die Qualified-Strukturen verweisen kann, dann kann man mit Likerec(*All) ebenso umgehen.
In neueren Versionen wird Qualified auch auf den F-Bestimmungen erlaubt.

Lehnt dein Compiler den eval-corr ab, gibt es 2 Möglichkeiten:
a) es gibt ihn noch nicht.
b) die beteiligten DS'n sind nicht qualified und/oder es wurden keine passenden Namen gefunden.

Kommen wir nun zu deinen Versuchen:
Ein "EXFMT Format" verwendet die I- und O-Felder aus der F-Bestimmung, ein "EXFMT Format Struktur" verwendet ein DS mit Likerec(*all).
Eine Subfile kann nur Read/Write/Update und kann daher nur mit *Input bzw. mit *Output-DS umgehen, der Compiler meckert das sogar an.
Gibt es keinen eval-corr, muss man die Feldinhalte manuell einzeln übertragen.

Aber um zu deinem Ursprungsproblem zurückzukommen reicht hier wirklich ein einfacher Verteiler und ein allgemeine Prompt-Funktion:

d MyPrompt PR 100 varying
d Feldname 10

select;
when CsrFeld = 'FELD1';
Feld1 = MyPrompt('KDNR'); // Auswahl Kunden-Nr (z.B. per Matchcode)
when CsrFeld = 'FELD2';
Feld2 = MyPrompt('Tab:47'); // Auswahl aus Tabelle 47
:
endsl;

Alles andere ist nur Overhead den anschließend kaum einer versteht.

[BenderD]

Jede Variable gibt es im gesamten Programm nur ein einziges Mal.

... es sei denn, man hat in einer PF/LF eine Integer drin und dasselbe Feld in einem DSPF, da macht es eine packed draus (hat mich reichlich Nerven gekostet, als ich so ein Feld in einer Parameterschnittstelle drin hatte und die F Karte der LF rausgeworfen habe...)

Verwendet man einen Lesebefehl "READ/CHAIN Datei/Format Struktur", dann muss die Struktur per Likerec(*input) definiert sein, umgekehrt bei "Write/Update Format Struktur" muss die DS mit Likerec(*output) definiert sein.

... es sei denn, man hat V7R3 https://www.ibm.com/support/knowledg...rpgrelv7r3.htm
(im verlinkten Doc nach likerec suchen)

D*B