|
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 mailing list archive is Copyright 1997-2025 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.
