|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.