ACCEPT in COBOL: Cursor-Tasten als "Exception-Keys"

[Neptun]

Hallo!

Ist:
Bildschirm I/O mit Transaction-File (kein Extended Display, sondern mit READ / WRITE auf das Transaction-File)

Erweiterung:
Anzeige einer "Listbox"
Auswahl einer Zeile in dieser Listbox


Ist es möglich, wenn ich die "Listbox" (so würde man es unter Windoofs nennen) mittels Extended Display (*EXTACCDSP) erstelle, die Cursor-Tasten (rauf/runter) als "Exception-Keys" zu definieren? Sprich: Sobald Cursor-rauf oder Cursor-runter gedrückt wird, soll eine andere Zeile in der "Listbox" revers dargestellt werden. Quasi eine Simulation eines Balkens. Ist sowas auf der AS/400 denkbar/machbar?


Und noch eine Frage:
Kann ich das DSPF "QDLBACCDSP" in der QSYS nicht mit OVRDSPF für meine Anwendung ändern? Habe das in meinem Startprogramm (USRPRF) versucht, klappte aber nicht. Möglicherweise ein Problem der ACTIVATION-GROUP?

Schonmal vielen Dank im voraus

Gruß
Neptun

[Fuerchau]

Die Cursor-Tasten sind leider nicht abfragbar.
Die Displayfile ist auch nicht überschreibbar, da die DISPLAY- und ACCEPT-Anweisungen dynamische Ein-/Ausgaben sind.
Windows-Funktionen sind auf einem 5250-Terminal nicht möglich.
Es gibt aber eine ganze Reihe von Screen-Manager-API's, d.h., komplette Steuerung des Bildschirms durch eine Anwendung.
OfficeVision hat den Bildschirm in einen entsprechenden Modus setzen können.

[Neptun]

Hallo!

Danke erstmal für die Antwort. Das man die Cursor-Tasten nicht abfragen kann, hatte ich schon so vermutet.

Es steht nur OPM COBOL zur Verfügung, evntuell ILE COBOL, falls man OPM UND ILE Programme mixen kann.
OfficeVision scheidet aus. Gibt es diese ScreenManager API's (oder vergleichbare) auch ohne OfficeVision?

Hmm, man könnte den Cursor ja als Block-Cursor definieren. Der ist dann zwar nur ein Zeichen groß, aber damit könnte man mit den Cursor-Tasten die Zeile auswählen, welche man haben möchte, und dann über die Bildschirmposition des Cursors wüsste man auf welcher Zeile der User "ENTER" gedrückt hat.
Hmm, hoffentlich bekomme ich beim EXTENDED Display auch die Cursorposition zurück, beim Transaction-File war es kein Problem.


Gruß
Neptun

[Neptun]

ach so, noch was:
wenn QDLBACCDSP nicht per OVR geändert werden kann, dann würde das ja bedeuten ich müsste in der QSYS an dieser Datei eine Änderung vornehmen. Das würde ja für die ganze Anlage gelten! Denkfehler von mir, oder ist das wirklich nicht anders möglich?


Gruß
Neptun

[Fuerchau]

An dieser Datei ist keine Änderung möglich und nötig.
Was die Cursorposition angeht, dann schau dir den erweiterten Status an (Statusfeld 2).
Warum nimmst du nicht eine DDS-Displayfile ?
Diese Accept/Display-Steuerung ist eigentlich nur eine Notlösung und wirkt nicht besonders schön.

[Neptun]

Hallo!

"An dieser Datei ist keine Änderung möglich und nötig."
Hmm, ich habe definitiv eine Änderung an der Datei QDLBACCDSP vorgenommen, nämlich RSTDSP(*NO) gesetzt, und dies hat auch funktioniert. Verstehe deine Aussage nicht!?

Naja, vielleicht muss ich es tatsächlich über ein zweites Transaction-File mit DDS lösen ...
Sehe ACCEPT/DISPLAY eigentlich nicht als Notlösung, man ist damit flexibler.


Gruß
Neptun

[Fuerchau]

Naja, so eine Änderung gilt bei mir nicht als "Änderung".
Ich sehe die Accept/Display-Variante als erheblich komplizierter im Sinne einer Bedienerführung.
Der User kann nicht erkennen, welches Feld denn gerade Eingabefähig ist oder man gibt sämtliche Atribute (Underline) für nicht-eingabefähig wieder aus.
Eine Mehrfeld-Eingabe ist nur mit eingeschränkter Funktionalität möglich (Accept in Struktur und den Rest macht COBOL irgendwie).
Jede Eingabe muss mit Datenfreigabe (oder mit autoenter) übertragen werden und zwingt das Programm zur Aktivität.
Der Benutzer kann nicht mal so eben (zwecks Korrektur) zwischen den Eingabefeldern hin- und herspringen, und, und, und...
- Subfile's sind überhaupt nicht möglich
- Fenstertechnik ist nicht möglich
- Bezugszahlgesteuerte Farben/Attribute/Sichtbar/Unsichtbar nicht möglich
- Beschränkt auf 24x80
Erhebliche Einschränkungen in den "erweiterten" 5250-Möglichkeiten bis zur vollkommenen Unmöglichkeit.

Übrigens:
RSTDSP(*NO) sollte wirklich nur im OVRDSPF erfolgen und nicht an der Datei selbst, da sich manche Programme nun mal auf die automatische Wiederherstellung des Bildinhaltes verlassen.