× 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.



I use the INDARA keyword in the dspf, and the indicators are defined like
this:

      //*  indicators
     Dindicators       ds            99
     D Exit                    3      3n
     D Refresh                 5      5n

I've never run out of available indicators in RPGIV.  I don't name the Fkey
with the number of the actual key because different companies have wanted
the function mapped to different keys in order to be consistant with
existing pgms.  So I may have to change Exit to 1  1n but  the code doesn't
need changed from 'if  F3@Exit' to 'if  F1@Exit', for example.

Phil



> -----Original Message-----
> From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
> Behalf Of Nicolay, Paul
> Sent: Tuesday, March 19, 2002 8:52 AM
> To: 'rpg400-l@midrange.com'
> Subject: RE: Defining a function key...
>
>
> 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.
>
>
> _______________________________________________
> 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.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.