Re: Window format clearing the remainder of the screen

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sigh... not the "*INKC vs *IN03" holy war, again.

a)  *INKx is simple and to the point.   KA=F1, KB=F2, etc.  Not hard
      at all to figure out.  And it's immediately obvious what the
      programmer is doing.  Yes, it would've been nice if they were
      called "*INK1 - *INK24", but they were limited to 2-digit
      names.   Yes, it would've been nice if they didn't arbitrarily
      skip over *INKO.  But, even with these complications, it takes
      5 minutes to learn.

b) *IN01, *IN02...  Yes, it's easy to figure out what these are when
      things are working, but there's an added step when things aren't
      working of verifying that *in01 is used for F1 and only for F1,
      and the same for *IN02-*IN24.  Is that difficult?  No.  But it's
      one step of complication above *INKx, and provides very little
      benefit.   (Unless the idea of C being the 3rd letter of the
      alphabet confuses you)

c) AID bytes.   This is EASILY more complicated than the two steps
      above combined.  It works great.   And it lets you use nicely
      named words like "KEY_F1" to represent your function keys.
      But... it's a GREAT DEAL more complicated than the indicator
      approach, and the end result is EXACTLY THE SAME.  What ever
      happened to "K.I.S.S."?

Frankly, Simon, I find your tone frustrating.  Apparently in order for
my programming standard to be "decent" it has to follow your flawed logic.

I'm not an "ancient" RPG programmer.  I'm way beyond the curve when it
comes to modern coding.   Activation groups are 2nd nature to me.  I use
APIs every day.   I do network coding.  Stream file coding.  My shop,
unlike most, has been coding RPG IV since 1996.   I'm NOT a dinosaur.

(Though, frankly, I think "out of date" whenever I see a CASEQ in a
program, or code that's in all caps, or subroutine names that are
unnecessarily abbreviated to 6 chars long.)

I use the *INKx indicators because they are THE MOST INTUITIVE OF THE
OPTIONS AVAILABLE, not because I'm ancient.   I just dont see how you
could POSSIBLY be confused by the *INKx indicators.


On Tue, 19 Mar 2002, Simon Coulter wrote:
>
> 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.
>