Unterschiedliche Bildschirmgrößen in EINEM Displayfile

[Starocotes]

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?

[Fuerchau]

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

[Starocotes]

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.

[hoersterp]

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)
.

[Fuerchau]

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.

[kitvb1]

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:

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:

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.

// 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.

[hoersterp]

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.

[Fuerchau]

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.