Re: Determining *DS4 support

Thanks Douglas. All this info makes me wish I had the opportunity to do more
interactive programming. These days it's mostly batch stuff <sigh>...

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax

From: "Douglas Handy" <dhandy1@bellsouth.net>
> >Was there any particular reason to use the API over the INFDS method?
Does
> >the INFDS return incorrect info? It seemed a lot shorter...
>
> I do it for several reasons:
>  - The INFDS requires the DSPF to already be open.  DSM does not,
> allowing you to determine the capability prior to opening a DSPF.
>  - The INFDS reports 24x80 if no DS4 formats exist in the display file
> since, for the DSPF, the max rows/columns is DS3 format.
>  - I can put it in a service pgm with numerous other related routines,
> making the test a simple matter of coding the subprocedure call, which
> will then be similar to other tests I may want to make which the INFDS
> can not handle.
>
> For example, my service program not only has a routine to check if the
> device is *capable* of 27x132, it has another one to determine the
> *current* state of the device.  This can be important in called
> programs which put up a window, because although the device is capable
> of 27x132, it may not necessarily be in that mode.  Like SEU, I think
> it is important to give the user the *option* to run in 24x80 if they
> prefer, even if the device is capable of 27x132.  I want windows to
> appear in the proper mode, without the need to pass parameters to
> subprograms to tell it what mode to use.
>
> Other routines in the service program return whether or not the device
> is capable of color, or "enhanced" user interface options, or GUI-like
> constructs like real borders, or extended foreground colors, or has a
> mouse attached, etc.  It is a simple matter to make short wrapper
> routines to test various attribute bits from QsnQry5250 or other DSM
> apis, and you can name them such that the intent is clear and program
> readability is improved.


> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---