× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



David,

We don't use indicators for function keys... there's just no reason for
(this way we can use them for complex screens that need lots of indicators
for the field attributes).

While I agree your suggestion is easy to read as well, it doesn't differ
much, ie.

        If      #Key = #F7

or

        If      #F7

both are excellent regarding readability.

Kind regards,
Paul

-----Original Message-----
From: dmosley@dancik.com [mailto:dmosley@dancik.com]
Sent: 19 March, 2002 14:42
To: rpg400-l@midrange.com
Subject: RE: Defining a function key...



Just curious, but doesn't anybody else RENAME their indicators.
Forget all that AID stuff, and even the *INKx stuff.

 * -- Indicators...
d ind@ptr         s               *   inz(%addr(*in))
d indicators      ds            99    based(ind@ptr)
 * ---- 01 - 29 : Functions Key indicators...
d  f3@exit                        n   overlay(indicators:03)
d  f6@cancel                      n   overlay(indicators:06)
d  f7@exit                        n   overlay(indicators:07)
d  f12@cancel                     n   overlay(indicators:12)
d  pagedown                       n   overlay(indicators:25)
d  help@key                       n   overlay(indicators:29)


To me it makes the code more legible to read,  IF  F3@EXIT,    or IF
F3@EXIT = YES.
I was also told to make your code as simple as possible.  Not for you, but
for the poor slob that has to come in behind you, and read your code.



David L. Mosley, Jr.
Systems Analyst
2000 CentreGreen Way
Suite 250
Cary, NC 27513



                    "Nicolay, Paul"
                    <paul_nicolay@mer        To:
"'rpg400-l@midrange.com'" <rpg400-l@midrange.com>
                    ck.com>                  cc:
                    Sent by:                 Subject:     RE: Defining a
function key...
                    rpg400-l-admin@mi
                    drange.com


                    03/19/02 08:32 AM
                    Please respond to
                    rpg400-l






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.


_______________________________________________
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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.