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


  • Subject: Re:Named Indicators...
  • From: "Denis Robitaille" <DRobitaille@xxxxxxxxxxxx>
  • Date: Wed, 18 Aug 1999 11:30:30 -0400

Just to give a different perspective. Here, we NEVER use indicator for function 
keys (no inkc, no in03). Instead, we use the IOFeedback (infds) area of the 
display file to determine the key pressed. So our code look like:

 if  KeyPress = F03

Where KeyPress is a variable from the feed back area and F03 is a constant 
define in a /copy member. This works great, no confusion, no indicators.

One extra benefit, this way not only the function key, but all keys can be 
processed that way.

Example:

select
when  KeyPress = Enter
...
when KeyPress = PageUp
...
when KeyPress = PageDown
...
when KeyPress = F6
...
When KeyPress = F12
...
endsl


Denis Robitaille
Cascades Inc
819 363 5187
fax 819 363 5177
DRobitaille@cascades.com

>>> "Scott Klement" <infosys@klements.com> 08/18 1:51 AM >>>
Marc,

Your solution is basing F3 on indicator 03, and F5 on indicator
05.  The original poster was looking for a way to base on KC and
KE, instead of 03 and 05.

Now -- to EVERYONE on the list:

Personally (and this is my opinion, many people have already told
me I was nuts)  I prefer to see *INKC or *INKE used instead of
*IN03/*IN05, and I also prefer to see *INKC over a "named indicator".

When I'm trying to figure out someone's code and I see this line:
C                   if        *IN03 = *On

I now have to search the source code to see what *IN03 is.   Since
its actually defined in the DDS, I won't find it.   I'll then search
the DDS, and I'll find that *IN03 is actually F3.

When I see:
C                   if        F3 = *On

I, again, now have to stop my reading of the source, search to see
what F3 is.  Find out that its based on *IN03 in the D-specs.
Now I have to search for BOTH F3 and *IN03 throughout the RPG code
to find out that its not defined.   Now I have to search all external
descriptions for F3, plus I have to search the DDS for 03.  Finally
I determine what it is.

When I see the line:
C                   if        *INKC = *On

I now know EXACTLY that this line does without having to search the
code at all.

People use "named indicators" because they don't think that *IN03
is "self-explanatory".   However, *INKC  *IS* self-explanatory, and
actually is MUCH MORE SO than a named indicator.

Sure, I can usually assume that "F3" is the same as *INKC.  But, I
know that as soon as I make that assumption, this will be the one
time that its not.

Sure, it doesn't take me more than a few seconds to determine what
a given indicator or named indicator does.   BUT, if I'm reading a
8000 line program, and I have to stop 20 different times to try to
figure out what a named indicator is, I'll get irritated.

Thats my 2 cents.

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.



zylka.marc@westpoint-stevens.com wrote:
>
> Tim,
>
>   This is what I use and it works well.
>
> DIndicators       DS                  Based(IndicatorP)
> D  F3                        03     03
> D  F5                        05     05
> D  F12                       12     12
> D  Eof_SKU                   90     90
> DIndicatorP       S               *   Inz(%Addr(*In))
>
> Marc
>
>
> ____________________Reply Separator____________________
> Subject:    RE: Named Indicators...
> Author: <RPG400-L@midrange.com>
> Date:       8/17/99 9:36 AM
>
>   79 /*****************   Map the function Keys *****************/
>       80 d InKa            s               *   inz(%addr(*inka))
>       81 d  FunctionKey    ds                  Based(InKa)
>       82 D    F3                           N   Overlay(FunctionKey:3
>
>     Thanks, tim
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com 
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.