Tips and Techniques: Eliminate Function Key Response Indicators

[MCWebsite.Staff]

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
** This thread discusses the Content article: Tips and Techniques: Eliminate Function Key Response Indicators **
This is a discussion about Tips and Techniques: Eliminate Function Key Response Indicators.

Click here for the article.

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Just give another name to the SYS36 *INKA, *INKB, *INKC indicators. It is such a simple change anf for years they do no do it. My suggestion is to use *INF01-*INF24 or more simple: *F01 - *F24. expample: select when *INF03='1'[*]INLR=*ON ENDSL Why use /COPY directive where it is up to the individual programmer, if something could be standard.

[TBarstow]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
I don't see anything wrong with coding C* if F5 pressed, refresh C If *In05 C refresh code ... C EndIf or using the select/when if appropriate While I agree that the *InKE is cyptic, if the indicators match and a comment line is used, I think its easier than the FKEYS method. If I needed the indicator to be used later in the calcs, I would probably do something with named indicators. C* if F5 pressed, refresh C If *In05 C Eval Refresh = *on C EndIf then later test C If Refresh C do stuff ... C EndIf While I am doing basically the same thing, I use much fewer lines of code, don't need the /COPY, and should be obvious to any future maintenance efforts.

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Indicators are there if you use them or not... I do not see any value in using field names instead of an indicator. It has been my standard for years to use the corresponding indicator for the command key. My code is very compact and is easy to change/read and I do use indicators.

---

Code

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
( this is a duplicate of the reponse to another article : http://www.mcpressonline.com/mc?Disc...loc=.6b20336d) Bob, I'm surprised to you advocate this option instead of using an INDDS to allow: dou exitPressed What's your reasoning for not advocating INDDS? Charles

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Just a question, Why is it that almost every time I read an article on tips and techniques by Robert Cozzi Jr I get the feeling of superiority coming through the words he is writing? Just because Robert Cozzi Jr doesn't like a certain way of coding doesn't mean it is the wrong thing to do. If a programmer keeps his code tight and well documented then that should fine. Just because newer methodology has been introduced does not mean the old tried and true methods should be abandoned. If it isn't broke, why fix it? My advice to all readers is this. If you see a tip or technique that you think would be beneficial to you and your company then by all means use it. If you do not see a need to use it and continue using your "OLD" methodology then that is fine as well.

[jcamden]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
I don't respond to these things often, but I couldn't let this one just pass by. I find Bob's assertion that "Using the *INKx indicators is one of the worst things you can do in RPG IV..." to be unfounded. He is certainly welcomed to his opinion, but just because he doesn't like something, doesn't make it unusable. It's just another consultant's opinion. In my experience they have several benefits. They are set on for you and they are consistently reset for you. When used as designed, they have only one meaning. Some of the most difficult debugging is when someone has used CAnn(xx) keyword in one screen and not all screens and then the indicator is left on by D/M. Or the "common" *INnn indicator is used for something else. I would have preferred if IBM had named them differently (like *INF01-24, but that goes back to RPG II) but they work as defined. I agree with CharlesWhalen, "If you do not see a need to use it and continue using your "OLD" methodology then that is fine as well."

[TonyT]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
All- As a New Year's resolution. Discard your BAD OLD DAYS OF DOING THINGS. What is BAD though depends upon the beholder.

[David Abramowitz]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
There are a lot of responses that I agree with here. I think it is a dangerous game to play, when you try to tell programmers how to code. Part of the problem with RPG developments over the past eight years or so, is that many of the newer opcodes, or mannerisms merely mimic existing functionality. So if someone says that it is better to use FOR instead of DO, or LEAVESR, etc. etc. etc. I would reply that there is really no difference, and most AS400 shops have a sixteen year compendium of working running programs full of things that at least one programmer will dislike. IMO, the only universal personality trend among programmers that I have noticed, is each coder believes their own code and style to be superior to anyone elses. Dave

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Having to maintain a program that uses them. actual code: C *INKE IFEQ '1' C BYACCT IFEQ 'Y' C MOVE *ON *IN54 Got it? Trying to figure out what inkr is drives me crazy, since the dds doesn't say anything like that (it's f17). Since the dds has to use 2 digit numeric indicators for fkeys, the rpgle should have some kind of direct correspondence. I have to maintain a bunch of code left by someone who loved *INK_ and if I meet him in person I'll bludgeon him with a copy of Modern RPG. There are 25 function keys, and 01-25 match up nicely.

[buck.calabro@commsoft.net]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Hi Dave, > There are a lot of responses that I agree with here. I > think it is a dangerous game to play, when you try to > tell programmers how to code. This is very wise. When I tutor new folks, I try to pass on the idea that their code should more or less look like the existing code. Extreme style deviation from the rest of the code base just makes it harder to maintain. On the flip side, hewing rigidly to standards set in the punched card era means that progress is hard to come by. There _is_ a middle ground, however, and that is instead of telling programmers HOW to code, tell them WHY. Let them work out the HOW as much as practicable. I try to teach standards as a way to make decisions easier. Like naming conventions. The whole point is not to force programmers to mechanically generate variable names; it's to free the programmer from the necessity of deciding on yet another variable name. All too often, those decisions turn into X, X1, X2, X3... So the maintenance programmer (me!) has to try to either figure out if I should re-use X2 or create a new variable X4 and compound the mess. An example is Bob's advice to use sub-procedures. This is great advice! Not because it comes from Bob, but because it offers us the opportunity to use local variables and lifts so many restrictions, including variable names. Now I can use X in each sub-procedure without worrying about the impact on the mainline, or on other sub-procedures. But not because The Boss issued an edict to use procedures Or Else, but because it's a good idea. --buck

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
"every time I read an article on tips and techniques by Robert Cozzi Jr I get the feeling of superiority coming through the words he is writing?" After a certain time, professionals gets "opinionated". An opinionated person is hated by many and loved and valued by many. Bob Cozzi is a legend and has to be opinionated. So dont let the tone of an opinionated person think wrongly about him. Actually none of the techniques Bob Cozzi mentioned are new. I use newer techniques e.g. suggestion 2. I not only use INFDS to eliminate *INKx, I also use INDDS to eliminate all *IN(x)! Compare the following one-line "SLICK" C style code I use instead of the Bob's "Primitive" code in suggestion 6. SHPDTE= %int(%char(%date(INVDTE:*ISO)+%days(WKDAYS):*ISO0) ); Now tell me, dont you get the feeling of superiority coming through the words I write? LOL

[OzzieH]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
It depends on the one who follows behind the beholder. Anything is better than "when *inkc". Using, "when fkey = F03", is as good as anything...it's very hard to misinterpret

[buck.calabro@commsoft.net]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
> It depends on the one who follows behind the beholder. This is absolutely right! > Anything is better than "when *inkc". Using, > "when fkey = F03", is as good as anything... > it's very hard to misinterpret And here is a perfect example! I came from S/3, then S/38. 'Exit' was F1, not F3. In this case, many existing programs used indicator 01 to mean 'Exit', while most of the new ones use indicator 03 for that purpose. So, better than 'when fkey = F03' is 'when fkey = EXIT' Of course, as just described, better depends on the NEXT guy's opinion! :-) --buck

[Guest.Visitor]

Tips and Techniques: Eliminate Function Key Response Indicators

** This thread discusses the article: Tips and Techniques: Eliminate Function Key Response Indicators **
Hey, speaking of sub-procedures, which I use a lot, how do programmers feel about putting subroutines in sub-procedures? Procedures are usually short pieces of code but to avoid duplicating code in a procedure, or having a long "mainline", I sometimes create little SUBSRs and EXSR those from the procedure mainline. Do other programmers create other procedures inside the procedure and call them, or are all your prototypes global? Just curious, since I've never read anything that addresses this topic. Most examples show how to get the day of week or day name in a procedure which is only a few lines of code. Chris