Re: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What'sthe difference!!!)

David,

I've just started using these APIs and I'm trying to find the parameters on
the QsnCrtWin API that controls the window boundary character and color.  I
believe that the default is a blue line.

Any help is greatly appreciated...

Joe
----- Original Message -----
From: David Morris <dmorris@plumcreek.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, April 13, 2000 5:26 PM
Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What'sthe
difference!!!)


> Dave,
>
> I know you are just testing a concept, but I'd stick with dynamic screen
APIs
> over program described display files.  After using the dynamic screen APIs
> almost exclusively for a couple of years and seeing the advantages, I
wouldn't
> go back to DDS.
>
> David Morris
>
> >>> dshaw@spartan.com 04/13/00 11:36AM >>>
> Dan,
>
> Responses in-line.
>
> > -----Original Message-----
> > From: Bale, Dan [mailto:DBale@lear.com]
> >
> > Dave,
> >
> > I beg to differ.  QPRINT & QSYSPRT are indeed printer file
> > objects, but they
> > are not externally described.
>
> DSPFD of QSYSPRT shows that it has 1 record format with 0 fields defined
in
> it.  Hmm, I see the system allows me to create a display file with the
same
> type of setup.  Now, if I write a program to use that, what happens?
>
> > Still, no one has answered the question.  Is it possible to
> > do meaningful
> > screen I/O with a display file created with SRCFILE(*NONE)
> > using only RPG
> > I-specs and O-specs?  If there is, I can't see how it could
> > be as simple to
> > code as internal printer file O-specs; you and someone else
> > mentioned UDDS -
> > enough said?
>
> Well, based on a trivial test I just did, I must say YES!  I created a
> display file named TEST using SRCFILE(*NONE), then wrote this ugly little
> RPG III program to use it.  I didn't use cycle control <grin>, but I used
> this display file just as I would QSYSPRT if I could read it and LO!  IT'S
> ALIVE!!! <vbg>  I'm not sure whether it could or how it would support
> function keys, since the display file doesn't provide for them, but
function
> keys are a convenience that we've gotten used to, not a requirement for a
> practical screen-handling program.  Set up the hex attributes that you
want
> for the screen as constants and just go to program-described town!
>
> Here's the RPG:
>
>      FTEST    CF  F    1919            WORKSTN
>      ITEST    NS
>      I                                        1   1 DUMB
>      C                     MOVEL'TEST'    TEST1   4
>      C                     EXCPT
>      C                     READ TEST                     90
>      C                     SETON                     LR
>      OTEST    E
>      O                         TEST1      4
>
> > Ah yes, workstation files using the primary cycle!  I think
> > there was a
> > point where the only choice you had for workstation files on
> > a S/34 was to
> > define it as primary.  Only later did we have the option to
> > define it as a
> > "D"emand file.  (Or was that just the way it was introduced
> > to me? <g>)
>
> Yeah, I've never worked on a /34 (I was working on Data General NOVAs back
> then), but I've heard that.  I think the original version of the program I
> described was that old.  Seemed very odd seeing something like that on a
> /38.
>
> Dave Shaw
> Spartan International, Inc.
> Spartanburg, SC
>
> +---
> | 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
+---