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.

[E305GL]

nunja dass mit den nerven... kann ich nur bestätigen. daher verwenden wir seit 1984 nur mehr den freien 52520-datenstrom, ersparen uns das Compilieren und können am Bildschrim auf während der Laufzeit machen was wir wollen... ja selbst das ansprechen einzelner Pixel in den 7 grundfarben ist möglich, dieses thema im Forum abzuhandeln würde den rahmen sprengen sonst heißt's gleich wieder da spamt einer; auf wunsch werden Informationen zugesandt