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