Re: Window format clearing the remainder of the screen

Hello Don,

You wrote:
>Actually, I do an EXFMT on the SCRN1C format already.  The only time I've
>ever done a separate WRITE and READ is when I have more than one format
>with input capable fields and that is very rare.   I also write the
>SCRN1K format before the EXFMT of SCRN1C.  As for the OVERLAY on SCRN1K,
>I figured it to be necessary to avoid clearing the prior format from the
>screen.

Using EXFMT on SCRN1C means writing SCRN1K first but when I did that I was
told the window didn't exist, hence my example code using WRITE and READ.
I presumed you did the same.  If you don't get the problem of the window
not existing then your code must be doing something different to cause the
window to be created before writing SCRN1K (perhaps writing the control
record to erase the subfile or something like that).

OVERLAY is only needed on subsequent formats in the same window.

>And yes, we have major interface problems.  We're moving to a more normal
>use of function keys (F3 for exit, F12 for previous, etcetera), but this
>system will be gone by next year anyway so we're not putting much effort
>into retrofitting code.

As long as you are aware of the issue that's half the battle.  I just
wanted to point it out.

>Now what is this AID byte?  I guess I should look that up.  I have always
>been under the impression *INKx was understood by the vast majority of
>RPG programmers and thus a good practice to make programs maintainable by
>outsiders.

While use of the *INKx indicators could be classed as a style issue I
think they should be avoided.  Quickly, what is key *INKM - don't count on
your fingers, sorry you took too long.  Compare that with what key is
*IN13 -- instant knowledge! (presumming decent coding standards).

Using the *IN01 to *IN24 indicators for the F-keys and *IN25 to *IN31 for
the remaining engraved keys (HOME, ROLLUP, HELP, etc.) is better than the
*INKx rubbish.

Better still is to use the AID byte found at position 369 in the display
file feedback data structure.  Each AID key (read as a key that sends a
response to the host) has a defined value -- documented in either the DDS
Reference or the Data Management Guide (I forget now, I sorted this
technique out decades ago).  Here are the F-spec and D-spec definitions.

FDSPF      CF   E             WORKSTN INFDS(DSPDS)

DDSPDS            DS
D  cfKey                369    369

Then you can write C-specs that look like (RPG III but that's what I had
to hand):

 * Handle user action
C           $F03      CASEQCFKEY     ENDPGM            Clean up
C           $F05      CASEQCFKEY     REFRSH            Refresh display
C           $F06      CASEQCFKEY     CREATE            Create object
C           $F09      CASEQCFKEY     RTVCMD            Retrieve command
C           $F10      CASEQCFKEY     CMDENT            Command entry
C           $F11      CASEQCFKEY     ALTVW             Alternate view
C           $F12      CASEQCFKEY     ENDPGM            Clean up
C           $F17      CASEQCFKEY     SRTLST            Sort list
C           $F23      CASEQCFKEY     NXTOPT            Next options
C           $F24      CASEQCFKEY     NXTKEY            Next F-keys
C           $ROLUP    CASEQCFKEY     BLDSFL            Next SFL page
C           $CLEAR    CASEQCFKEY     DUMP              Dump program
C           $F04      CASEQCFKEY     PROCES            Process options
C           $ENTER    CASEQCFKEY     PROCES            Process options
C                     CAS            BADKEY            Invalid F-key
C                     ENDCS

which to my mind is much clearer than either of the *INKx or *INnn forms.
Note that named indicator support in RPG IV means you could accomplish
similar code clarity by using an indicator data structure which would be
an acceptable alternative to the AID byte.

Only ancient RPG programmers know what *INKx indicators are and even they
need to translate them once they get past *INKF or *INKG.  They are
obscure, indirect, and should be avoided.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------