|
midrange.com
Hi,
I don't understand the comments about the AID byte in the mail
below...EASILY versus GREAT DEAL more complicated ?
Anyway, I guess the basic goal for programming should be the creation of
readable programs to improve maintenance. In that context I don't see why
people vote for obscure things like *INKG ?
I doubt anybody can argue that it is easier than a test like
If #Key = #F7
While all the necessary pre-requisites for this can be stored in a
copymember, I don't see the point why this should be a GREAT DEAL more
complicated ?
Hopefully the end result is always the same, but this is no reason to create
obscure coding styles (after so many years, I at least, still need to count
on my keyboard before I know which function key was targeted).
Kind regards,
Paul
-----Original Message-----
From: MWalter@hanoverwire.com [mailto:MWalter@hanoverwire.com]
Sent: 19 March, 2002 14:21
To: rpg400-l@midrange.com
Subject: Re: Defining a function key...
Ditto!!
Thanks,
Mark
Mark Walter
Sr. Programmer/Analyst
Hanover Wire Cloth a div of CCX, Inc.
mwalter@hanoverwire.com
http://www.hanoverwire.com
717.637.3795 Ext.3040
The TrekTeam
<trekteam@pacbell To: rpg400-l@midrange.com
.net> cc:
Sent by: Subject: Defining a
function key...
rpg400-l-admin@mi
drange.com
03/18/02 07:21 PM
Please respond to
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.
>
_______________________________________________
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.
_______________________________________________
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.
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.
