Re: Window format clearing the remainder of the screen

Hello Scott,

You wrote:
>Sigh... not the "*INKC vs *IN03" holy war, again.

And I should know better than to consider responding ...

>a)  *INKx is simple and to the point.

They are not simple and to the point at all.  They involve a mental
translation that is entirely unnecessary.

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

It's not the first few that bother me.  It's the last few.  No-one (even
those who think they can) can tell me what *INKI or *INKP is quickly
enough to avoid the mental translation.  The other argument you raise
regarding *INnn being used elsewhere is simply specious.

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

It's only more complex in the initial setup.  Everything can, and should,
be hidden away in copy members.  Copy members can hold the key
definitions, the feedback data structure, etc.  The advantage is directly
readable and intuitive code.  *INKx is not intuitive -- see response to a)
above.

>Frankly, Simon, I find your tone frustrating.

Oh dear, how sad, never mind!  Although I think you have a different word
in mind -- tone cannot be frustrating.

>Apparently in order for my programming standard to be "decent" it has to
>follow your flawed logic.

Aside from the fact that my logic is not flawed, I see nothing else wrong
with the above sentence.

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

Not a dinosaur?  Really?  Yet you think *INKx is obvious,
self-documenting, and simple?  Res ipsa loquitur!

1996?  Hmm, I've been doing RPG IV since at least '95 and ILE since '93.
Everything else in your list is standard fare to me too so don't start a
pissing contest.

>(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 did point out that the example code I used for the C-specs was RPG III
hence the six character names and uppercase variables, I guess you missed
that statement.  I do actually prefer RPG op-codes in uppercase but don't
mind if someone else chooses to use lowercase or mixed case -- it doesn't
affect the legibility.  The CAS construct is still useful for handling
function keys and subroutines still have their place -- not everything
should be replaced by procedures.

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

They are not intuitive regardless of what you might think.  Supposedly
rational people manage to harbour both logic and faith within the same
mind so I have no doubt you can use modern techniques in some places and
continue archaic practices elsewhere.

I'm not confused by *INKx, I know what they are.  I do not like them for
the reasons stated above.  You can choose to disregard those arguments but
the fact remains that any of the three other methods (*INnn, AID, or named
indicators) makes the code far more obvious and intuitive than *INKx.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------