Citation de Hurrican le 14 mars 2007, 15 h 07 min

Pour donner un exemple.
J'ai un programme A qui est en 24x80.
J'ai un programme B qui est en 27x132.
Ils appellent tous deux le programme C, qui est censé affiché une fenêtre sur le format en cours du programme A ou B.
Le problème est que :
- Si je défini dans les DDS de l'écran du programme C, l'écran primaire comme étant 24x80, l'appel depuis le programme A fonctionne, mais celui depuis le programme B efface l'écran.
- Si je défini dans les DDS de l'écran du programme C, l'écran primaire comme étant 27x132, l'appel depuis le programme B fonctionne, mais celui depuis le programme A efface l'écran.
L'utilisation de DSPMOD pour afficher soit en 27x132 soit en 24x80, supprime en fait le mot clé ASSUME qui me permet de faire du fenêtrage. 🙁

Il me reste la possibilité de doubler chaque écran appelé, et d'ouvrir l'un ou l'autre selon, mais çà devient lourd à gérer !!!

Citation de Serge Gomes le 14 mars 2007, 16 h 45 min

Il me semble avoir déjà rencontré ce problème, je crois qu'il faut créer 2 formats "fantomes" WINDASSU et WINDKEEP.
J'ai gardé un source DDS qui, à l'époque, avait résolu le problème.
A tester donc....

A DSPSIZ(24 80 *DS3 27 132 *DS4))
A REF(*LIBL/REPERTOIRE)
A PRINT
A R WINDASSU
A ASSUME
A OVERLAY
A 24 80' '
A R WINDKEEP
A KEEP
A OVERLAY
A R U$1600F1
A WINDOW(10 4 8 70)
A CF04
A CSRLOC(CURLIG CURCOL)
A OVERLAY
A WDWBORDER((*DSPATR RI) (*CHAR ' -
A '))
A N30N31N32
A N33 RMVWDW
A CURLIG 3S 0H
A CURCOL 3S 0H
A LIBSTE 30A O 1 1COLOR(BLU)
A 1 34'Commande N°:'
A WNUCMD 9A O 1 47COLOR(BLU)
A 22 4 1'Remise camion complet (O/N) :'
A 20 5 1'Code grossiste. . . . . . . :'
A 21 6 1'Code nature de blocage. . . :'
A WCODRE 9A B 3 31
A N19 COLOR(BLU)
A 19 COLOR(YLW)
A N19 DSPATR(PR)
A 30 ERRMSGID(MSG0000 QTEMP/MSG 30)
A 21 ZCDEBL 3A B 6 31COLOR(YLW)
A 33 ERRMSGID(MSG0000 QTEMP/MSG 33)
A 21 ZLIBBL 30A O 6 41COLOR(BLU)
A 3 1'N° commande du représentant :'
A 20 ZCODGR 9A B 5 31COLOR(YLW)
A 32 ERRMSGID(MSG0000 QTEMP/MSG 32)
A 20 ZLIBGR 30A O 5 41COLOR(BLU)
A 22 ZCODRC 1A B 4 31COLOR(YLW)
A 31 ERRMSGID(MSG0000 QTEMP/MSG 31)
A 7 2'F4:Liste Entrée:Valide'
A COLOR(BLU)

Citation de Hurrican le 14 mars 2007, 18 h 05 min

Il devait y avoir un autre "truc". 😉
Comme çà, en écrivant, ou non les formats, çà ne change rien.
J'ai beau chercher sur les différents forums, je ne trouve personne qui ait déjà réussi çà. 🙁

Citation de Serge Gomes le 15 mars 2007, 8 h 31 min

J'ai pourtant une fenêtre de ce type qui fonctionne aussi bien à partir d'un écran 132 que d'un écran 80.
Le mot clé
DSPSIZ(24 80 *DS3 27 132 *DS4) doit être renseigné.
Il faut aussi dans le format WINDASSU écrire un espace en 24 80.

Si cela ne fonctionne toujours pas je peux transmettre par mail les dds complètes de la fenêtre.

Serge

Citation de Hurrican le 15 mars 2007, 8 h 49 min

Etrange, je ne vois pas déjà comment ta fenêtre peut s'ouvrir correctement sur un écran 132 colonnes, vu que le mot clé DSPMOD ne figure pas dans sa définition (et je l'ai testé comme çà, c'est bien ce que j'obtiens, un effacement de l'écran 132 avant apparition de la fenêtre).

Citation de Serge Gomes le 15 mars 2007, 10 h 14 min

Hurrican, j'ai envoyé un mail avec les dds complète d'une fenêtre que j'utilise régulièrement.

Citation de Hurrican le 15 mars 2007, 11 h 16 min

Merci pour le coup de main.
Je suis abasourdi...
J'ai fais des modifs et des modifs, rien n'a changé.
Ton DDS ne fonctionnait pas mieux...
Et puis, j'ai reconstruis mon DDS, en gardant une modif qui pour moi était essentielle par rapport à ton DDS (le fait de basculer grâce à DSPMOD les formats dans le bon mode écran).
Et là miracle ! Cà marche !

En fait, mon DDS était parfaitement correct à un détail près, qui pour moi s'appelle un bug IBM.
Dans mon DDS, l'écran principal était en 27x132, et le secondaire en 24x80.
Les mots clés DSPMOD étaient donc affectés à *DS3, quand nécessaire.
Le simple fait d'inverser celà, en mettant l'écran primaire en 24x80, le secondaire en 27x132, et en modifiant les DSPMOD en *DS4 (avec l'indicateur inversé bien sûr...), et hop çà marche ! 😆

En résumé : Ceci fonctionne A DSPSIZ(24 80 *DS3 -
A 27 132 *DS4)
A INDARA
A R BIDON
A 31 DSPMOD(*DS4)
A ASSUME
A OVERLAY
A 24 80' '
A R MENU
A 31 DSPMOD(*DS4)
A *DS3 WINDOW(*DFT 10 55 *NOMSGLIN)
A *DS4 WINDOW(*DFT 10 55 *NOMSGLIN)
Ceci ne fonctionne pas
A DSPSIZ(27 132 *DS4 -
A 24 80 *DS3)
A INDARA
A R BIDON
A N31 DSPMOD(*DS3)
A ASSUME
A OVERLAY
A 24 80' '
A R MENU
A N31 DSPMOD(*DS3)
A *DS3 WINDOW(*DFT 10 55 *NOMSGLIN)
A *DS4 WINDOW(*DFT 10 55 *NOMSGLIN)
Je m'en vais de ce pas, mettre à jour quelques DDS, c'est mes utilisateurs qui vont être contents ! 😀

Citation de Hurrican le 15 mars 2007, 17 h 46 min

La haîne !!! 😡
Si çà fonctionne bien sur mon 400 de développement en V4R5, çà ne marche pas sur l'AS400 de production qui est en V4R4...
Il ne me reste plus qu'à attendre qu'on autorise l'upgrade (ce qui aurait du être fait depuis longtemps ! )

Citation de remit le 27 septembre 2007, 17 h 41 min

Incidemment, je tombe sur cet article

Retrieving the Current Display Size in RPG IV
by Bob Cozzi

September 19, 2007 —

Return Current Display Mode and Screen Dimensions
Back in the later days of the System/38, IBM started working on a set of Windowing APIs for the 5250 display files. Those APIs, called Dynamic Screen Manager (or DSM), include a set of dozens and dozens of APIs that do more than you can ever want to do.
Two of those APIs are used regularly in my old green-screen code. I use them to determine the current size of the display. It's the old *DS3 vs. *DS4 mode dilemma, where you need to output a display format based on the current display mode.
The first API is QsnRtvMod. This API retrieves the current display mode (3 or 4) and returns that value to the caller. When DSM was being created, IBMers on the project couldn't for the life of them figure out where the current display status was kept. Hearing about this, I used my experience with MI and the internals of the System/38 and AS/400 to narrow down where it might be located. I then checked with an IBM Rochester engineer, who is still to this day one of the smartest people I've ever met.
He confirmed that I was on the right track and actually figured out how the Toronto programmer should go about retrieving that value. I forwarded it on to the programmer and, needless to say, this seemingly simple capability was needlessly complex and mysterious.
But the good news is she created QsnRtvMod to easily retrieve the display mode, regardless of the underlying complexities. The prototype for QsnRtvMod follows:

D QsnRtvMod PR extProc( 'QsnRtvMod ')
D mode 1A
D llHandle 10I 0 Const OPTIONS(*OMIT)
D error 16A OPTIONS(*VARSIZE)

The API returns the current display mode to parameter 1. Specify a one-position character field to return the mode, for example:

D DS3_mode C Const( '3 ')
D DS4_mode C Const( '4 ')
D mode S 1A
D errDS S 16A Inz(*ALLX '00 ')

/free
QsnRtvMod(mode : *OMIT : errDS);
if (mode = ds3_mode); // Normal mode
elseif (mode = ds4_mode); // Wide-screen mode
endif;
/end-free

The second parameter needs to be *OMIT, and the third parameter is the traditional API error data structure. I like to pass all hex zeros for this parameter so that the APIs ignore the parameter. It would be nice if we could just pass in the mode parameter, but that's why they make subprocedure wrappers.
The other API is a bit more specific on the display mode status. QsnRtvScrDim returns the current screen dimensions. So, for example, it returns 80:24 or 27:132.
The prototype for QsnRtvScrDim follows:

D QsnRtvScrDim PR 10I 0 extProc( 'QsnRtvScrDim ')
D rtnRows 10I 0
D rtnColumns 10I 0
D llHandle 10I 0 Const OPTIONS(*OMIT)
D error 16A OPTIONS(*VARSIZE)

The first parameter receives the current number of rows on the display; the second parameter receives the number of columns on the display. As in the other API, the low-level environment handle and API error data structure are ignored for our purposes.
Calling QsnRtvScrDim is simple, for example:

D rows S 10I 0
D cols S 10I 0
D mode S 1A
D errDS S 16A Inz(*ALLX '00 ')

/free
// Retrieve the rows and columns currently displayed
QsnRtvScrDim(rows : cols : *OMIT : errDS);
if (rows = 27 and cols = 132);
// Wide-screen mode
endif;
/end-free

The DSM APIs all begin with the letters 'Qsn' and can be located with the IBM API Finder. These two APIs only scratch the surface as to what you can do with them. One key point, as I've implied throughout this article, is that if you pass *OMIT for the low-level API, or pass in all hexadecimal zeros, the current display is used rather than a DSM environment virtual screen.
A great test program to write is to call both of these APIs in an RPG IV program and write the result to the joblog. Then assign the program to the attention key (SETATNPGM) and press ATTN while on Command Entry, then display a spool file (which will switch the display to 27x132 mode), and hit ATTN again. Then go look at the entries in the joblog. It is a pretty cool capability -- one that I used back in the 1980s when I wrote the first windowed 5250 application in 1984. It was called 'Partner ' and was a 5250 clone of the popular PC DOS SideKick application from Borland International.
I still have people using it or portions of it to this day, and it still works. Can you say that about any Windows-based application from 20+ years ago?