Re: Window in 2nd pgm?

If we think back to tubes (CRT's), the original devices were *DS3 (3180 and
3277 came along later IIRC).  I'd guess each CRT had a controller to manage
the screen, create characters, etc. and everybody defaulted to 24x80,
including the 3270 crowd (some of the 5250 design probably came from the
3270 product line).  Perhaps the System/38 workstation controller queried
the tube's (device) controller--not the workstation controller we all grew
to love)--to see if *DS4 was available.

When a *DS4 datastream hit the workstation, the device controller would
have to reset itself to handle smaller characters; this is why you can't
write a *DS4 display when *DS3 mode is active.  In the old days, the
hardware couldn't handle it, and to maintain backward compatibility, that's
never been changed/fixed.  When you have a graphics card, you can do just
about anything.

The behavior observed is called out in the explanation of the DSPMOD
keyword in your DDS reference manual; the manual references a "default
display mode" which is our *DS3.  Also this:

*"When a record with DSPMOD causes the mode to be changed, all records
currently on the display are deleted."*

Using the API QsnRcvMod, the program can determine what mode the screen is
in, and I'd guess that API talks to the System/38 controller.  The display
file InfDS may have a device type/model; the RPG manual isn't much of a
help and I'm not bored enough to root through functional reference manuals.

There is a workaround to this problem: start by setting an indicator from
QsnRtvMod.  *IN95 means *DS4.
Add this code to the DSPF header:
A                                      DSPSIZ(*DS3 *DS4)

And add this code to the non-subfile formats at the record level:
A  95                                  DSPMOD(*DS4)
A  *DS3                                WINDOW(*DFT 7 49 *NOMSGLIN)
A  *DS4                                WINDOW(*DFT 7 49 *NOMSGLIN)

If the display is currently in *DS4 mode, this logic merely tells the app
to write the display in *DS4 mode.

Good times...

On Fri, Aug 29, 2025 at 6:24 AM Charles Wilt <[email protected]> wrote:

> That only tells you the data for the open display file...
>
> Doesn't tell you what size was being used before the DSPF  was open (ie for
> the OP's case of making the popup window match)
>
> Also doesn't tell you what sizes the display actually supports ahead of
> time.
>
> Charles
>
>
> On Thu, Aug 28, 2025 at 5:29 PM Roger Harman <[email protected]>
> wrote:
>
> > I've never had to deal with this but is there some reason for not
> > declaring and using an INFDS for the DSPF?  Seems a lot easier than
> dealing
> > with the API.
> >
> > DEV_TYPE      CHAR(1) POS(272);    // Device type - *DS3, *DS4, etc.
> > NUM_ROWS    INT(5)     POS(282);    // Number of rows
> > NUM_COLS     INT(5)     POS(284);    // Number of cols
> >
> > Roger Harman
> > COMMON Certified Application Developer - ILE RPG on IBM i on Power
> >
> >
> >
> > -----Original Message-----
> > From: RPG400-L <[email protected]> On Behalf Of
> Charles
> > Wilt
> > Sent: Thursday, August 28, 2025 12:56 PM
> > To: RPG programming on IBM i <[email protected]>
> > Subject: Re: Window in 2nd pgm?
> >
> > Sorry...been to long and I was mis-reading the API name...
> >
> > QsnRtvMod - lets you determine if the current screen (last output) is 80
> or
> > 132 column
> > QsnQryModSup  - lets you determine if a device is configured to support
> 132
> > columns
> >
> > Details here
> > https://archive.midrange.com/rpg400-l/200011/msg00361.html
> >
> > HTH,
> > Charles
> >
> >
> > On Thu, Aug 28, 2025 at 7:22 AM Charles Wilt <[email protected]>
> > wrote:
> >
> > > Yes the code Mark linked to shows the check being called from the popup
> > > window.
> > >
> > > TLDR;
> > > The key to making our popup window display in the correct mode requires
> > > the following steps:
> > >
> > >
> > >    1. The (popup) display file should be user open (UsrOpn on the F
> spec)
> > >    so that we can set the size mode before the file is opened
> > >    2. Detect the current screen mode size by using the
> > >    Screen_SizeIs27x132 functio
> > >    3. Set the display mode size of our popup window program to the
> > >    current mode
> > >    4. Open the display file
> > >    5. Display the popup screen
> > >
> > > Ignore what's being done in the test driver.
> > >
> > > The QsnRtvMod API mentioned by another poster won't work, it simply
> tells
> > > you if a display supports 27x132.
> > > I've used that to display a message asking the user to call the help
> desk
> > > to get their session reconfigured as I had a new application that only
> > > worked on 27x132.
> > >
> > > HTH,
> > > Charles
> > >
> > >
> > >
> > >
> > > On Thu, Aug 28, 2025 at 6:57 AM Justin Taylor <[email protected]>
> > > wrote:
> > >
> > >> After reading the doc, I'm not sure if that API called from the window
> > pgm
> > >> will detect the screen of the calling program.  I'll have to test it
> and
> > >> see.  We may have to add an optional parm to the window pgm to
> override
> > >> the
> > >> default display size.
> > >>
> > >> Thanks
> > >>
> > >>
> > >>
> > >> On Wed, Aug 27, 2025 at 5:12 PM Mark Waterbury via RPG400-L <
> > >> [email protected]> wrote:
> > >>
> > >> >  Justin,
> > >> > The QSNRTVMOD will give you that information.
> > >> > Sample code can be found here:
> > >> >
> > >> >
> > >>
> >
> https://web.archive.org/web/20120116114604/http://provatosys.com/retrieve.html
> > >> > HTH,
> > >> > Mark S. Waterbury
> > >> --
> > >> This is the RPG programming on IBM i (RPG400-L) mailing list
> > >> To post a message email: [email protected]
> > >> To subscribe, unsubscribe, or change list options,
> > >> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > >> or email: [email protected]
> > >> Before posting, please take a moment to review the archives
> > >> at https://archive.midrange.com/rpg400-l.
> > >>
> > >> Please contact [email protected] for any subscription
> > related
> > >> questions.
> > >>
> > >>
> > --
> > This is the RPG programming on IBM i (RPG400-L) mailing list
> > To post a message email: [email protected]
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: [email protected]
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/rpg400-l.
> >
> > Please contact [email protected] for any subscription related
> > questions.
> >
> > --
> > This is the RPG programming on IBM i (RPG400-L) mailing list
> > To post a message email: [email protected]
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: [email protected]
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/rpg400-l.
> >
> > Please contact [email protected] for any subscription related
> > questions.
> >
> >
> --
> This is the RPG programming on IBM i (RPG400-L) mailing list
> To post a message email: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: [email protected]
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
>
> Please contact [email protected] for any subscription related
> questions.
>
>
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.