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



Hi Jon -

It has been available forever - or at least as long as RPG IV has existed.
It was in the very first release.

Since you mention it's ability to turn the indicator off if it is already
on, it is probably worth extending your example to _preserve_ the current
state of the indicator. e.g.

*In50 = (RRN1 > *Zero) or *In50

Of course we shouldn't be using nasty numbers anyway now should we <grin> -
so a better example might be:


Where SubfileDisplay is a named constant with a value of 50. If we have used the INDDS keyword to name our indicators, then it becomes even cleaner because it could read like this:

SubfileDisplay = (RRN1 > *Zero) or SubfileDisplay

You're dealing with a very bad example of preserving the prior state. Having SFLDSP indicator on even though the subfile is now empty, just because it previously had data, is NOT a good idea.


Speaking in general terms, I really like that the evaluated value replaces the current value. I use that kind of assignment statement a lot. I *always* code it with parenthesis around the comparison so that it is clear what is happening. Likewise, if I have an IF with multiple conditions, I always put the parenthesis around the various conditions to indicate the way the testing should be done, even if that is exactly the same as the what the compiler's built-in hierarchy would do.
E.g. I code
if (a = b) or (c = d)
even though
if a = b or c = d
would give exactly the same results.


Since RPGIV understands that an indicator is a boolean
true/false you don't need the "= *On" or "= '1'" <shudder!>.  So "If
*In(SubfileDisplay)" is equivalent to "If *In(SubfileDisplay) = *On" - and
"If Not *In(SubfileDisplay)" is equivalent to "If *In(SubfileDisplay) =
*Off"

I'm with you there. And to expand what I know you know, but others may not realize, this applies to any logical expression, including named indicators and BIFs.
E.g.
dow not %eof rather than dow %eof = *off
if %found rather than if %found = *on


The shorter source code MAY even generate shorter compiled code, depending on how smart the compiler is, particularly on the second line.

Without any special checking if %found would test the %found flag for a on status, then if true, execute the code inside the IF, whereas if %found = *on would compare the %found flag to a true value, then test the result of that comparison to see if it is true, then if that is true, execute the code inside the IF.

Maybe Barbara or Hans will chime in and let us know how smart the compiler is at eliminating redundant checking.

--
Ken
http://www.ke9nr.net/
Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.



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.