Defining a function key... -- RPG400-L

My vote, (are we voting?) goes to the *InK_ indicators...
No setup, no external definitions "CF07(07)" ???
And my code lines always have a comment, not only to reveal the actual,
numbered function key but what it does...
                    If     *InKG
F7=Print Screen  (<== This is just second nature)
                    .....
                    EndIf

Capt.j

----- Original Message -----
From: "Scott Klement" <klemscot@klements.com>
To: <rpg400-l@midrange.com>
Sent: Monday, March 18, 2002 6:35 PM
Subject: Re: Window format clearing the remainder of the screen


>
> 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.
> >
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>