-
Unterschiedliche Bildschirmgrößen in EINEM Displayfile
Hi
steht irgendwie auf dem Schlauch. Kann ich nicht unterschiedliche Bildschirmgrößen in einem Displayfile verwenden?
Also z.B. habe ich in einem Displayfile
Format001
Format002
Subfile001
SubCtr001
Format003
Format001, und die Subfile Formate sollen mit 132 Stellen dargestellt werden, der Rest mit 80. Geht das?
-
Das ist wie Raido Eriwan: Im Prinzip Ja, aber ...
Es sind verschiedene Sachen zu beachten:
Für die unterschiedlichen Formate musst du Bedingungsnamen setzen.
Display size condition names
Die Reihenfolge der Felddefinitionen ist genau zu beachten.
Du kannst keine Formate mischen.
Wenn du die DSPF dann an einem Terminal öffnest, dass keine Umschaltung erlaubt, bekommst du eine CPF-Meldung und der Open schlägt fehl, d.h., dass dein Programm dann nicht läuft.
Um tatsächlich flexibel zu sein, verwende ich 2 DSPF's mit USROPN, so dass ich auch bei einfachen Terminals beim Open feststelle, ob eine Umschaltung überhaupt möglich ist.
Weitere Erklärungen findest du hier:
DSPSIZ (Display Size) keyword for display files
Example: A horizontal subfile displayable on two display sizes
-
Zitat von Fuerchau
Du kannst keine Formate mischen.
Ich vermute das Du damit genau das meinst was ich aber will.
Alle meine Bildschirme könne sowohl 80x24 als auch 132x27. Das kann ich zu 100% sicher stellen.
Ich möchte das aus EINEM DSPF zum Teil Formate in 80x24 und zum Teil in 132x27 dargestellt werden.
-
2 Formate in einer DSPF
Hallo,
du kannst zur selben Zeit an einem Bildshcirm entweder 24x80 oder 27x132 anzeigen, beise zusammen aber nicht.
Wir haben bei uns Windows, die je nachdem, aus welchem Progamm sie aufgerufen werden, das eine oder das andere Format anzeigen.
Auf Dateiebene gibst du in der DDS
DSPSIZ(24 80 *DS3
27 132 *DS4)
an.
Auf Satzformatebene steuerst du dann mit Bezugszahl den Displaymodus
Bsp. Bzz 27 = DSPMOD(*DS4)
.
-
Mit Mischen meine ich auch nur die gleichzeitige Anzeige unterschiedlicher Formate.
Wie mein Vorredner schon sagt, durch Bezugszahl und Bedingungsname steuerst du, welche Darstellung das Format dann hat.
Beispiele findest du auf obigen Links.
Unter bestimmten Voraussetzungen lehnt der Compiler mit entsprechenden Hinweisen die Erstellung leider ab. Die Hinweise erklären aber den grund, es wird halt nicht alles unterstützt.
-
Sorry for the English, but this will be a long message.
If you are calling a 27x132 format pgm (even if defined with 24x80 as well), the caller's dspf must at least have the following specified:
Code:
DSPSIZ(24 80 *DS3
27 132 *DS4)
I have found that it is sometimes not the direct caller, but rather the next called pgm that will fail because of a format difference.
So this would look something like this:
Code:
pgma (24x80) calls pgmb (24x80) --> no problem
then pgma calls pgmc (both sizes) --> no problem
then pgma call pgmd (24x80) --> no problem
then pgma calls pgme (24x80) --> absturtz
then pgma calls pgmc --> no problem
then pgmc calls pgmb --> absturtz
** Why pgme crashes, but not pgmd, I don't know and didn't have the time (was not in the budget) to find out why.
To overcome this, and to avoid having to change many dspf's, you can do the following:
1. create a dummy dspf with both formats defined.
2. in your pgm, define your dspf and the dummy dspf, both as USROPEN.
3.
Code:
// open dummy size
open dum27x132;
write dummy1;
close dum27x132;
// open proper size
open in017gft;
.....
do whatever
.....
//EOJ
//set dummy size
close in017gft;
open dum27x132;
write dummy1;
close dum27x132;
Note: I used this technique to replace all the vendor's search pgms with our, without having to recompile or change any vendor pgms.
Last edited by kitvb1; 26-11-09 at 11:33.
Grund: removed duplicate word & added note
-
Unterschiedliche DSP-Größen in einem PRTF
Ja, das kann ich mir vorstellen.
Allerdings kann es auch durchaus reichen, wenn man nach dem CALL des Programmes mit den unterschiedlichen Formaten nach der Rückkehr in das aufrufende Programm die dort vorher auf dem Bildschirm verwendeten Formate mit WRITE wieder neu ausgibt, bevor das Programm weiterläuft.
-
Entscheidend für die automatische Wiederherstellung ist RSTDSP(*YES). Bei *NO muss man natürlich nach einem CALL den Bildschirm selber komplett wieder herstellen.
Problematisch wird es nur bei Anwendungen mit Fenstern oder teilweise Überlagerungen übergeordneter Bildschirme und ASSUME. Dann kann und wird es bei der Wiederherstellung zu Problemen kommen.
Man kann alternativ auch Low-Level-API's "zwischenschieben":
Screen Manipulation and Query APIs
Wobei hier eben Save-/Restore Screen interessant sind.
Similar Threads
-
By pwrdwnsys in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 15-02-07, 12:01
-
By steven_r in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 07-11-06, 11:01
-
By THH in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 19-12-05, 10:32
-
By THH in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 17-12-05, 11:51
-
By Eierton in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 21-07-04, 07:43
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks