×
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.
On 06-Dec-2013 10:53 -0800, Alan Campin wrote:
<<SNIP>>
You would always do
If LogicalField; (If True)
If Not LogicalField (If False)
Always is quite definitive :-) but rarely seems to occur in nature;
err... in programming. I have found a number of reasons to compose the
equivalence predicate to make the intent of the logic clearer to the
reader. Albeit, mostly when the "LogicalField" name is not well-named
so as to allow that implied-logical predicate to be intuitively
meaningful; e.g. given the poorly-named variable in "If policy_rider;"
already exists versus the better-named "If is_a_policy_rider;", then I
might desire coding instead:
"If policy_rider=cIs_a_policy_rider_vs_the_policy_itself;"
Where the constants come in
set the value of logical field obviously.
DisplaySubfileMessage = cTrue;
EditMode = cTrue;
DisplayMode = cFalse;
Condition is true or false.
I am unsure why *ON and *OFF are not just as good for those
conditions and the assignment; neither seems more clear than the other.
I might be missing something.?
Rather than something as bland as cTrue, why not use a constant-name
that has some meaning; e.g. cDisplaySubfileMessage having the value of
'1' [*ON] to indicate that a message subfile should be displayed:
DisplaySubfileMessage=cDisplaySubfileMessage;
Sometimes even a decently-named logical variable might be referenced
in a manner that is not as clear when the equal predicate is not
explicit. For exampl,e I find the following condition to be very clear
and preferable over an implicit logical condition:
If RowData.FieldNbr(i).hasValue = cIsNull then ; // has no value
outputBuffer.outputFieldNbr(i) = '-' ; // output a dash
The above predicate could instead have been any of the following, and
although the last is probably preferable as alluded in the quoted
message, I find the /reading/ of the condition to be /awkward/ by
comparison to making the equal predicate appear more like an IS NULL
predicate shown in the example above:
if hasValue = *ON
if hasValue = cTrue
if NOT hasValue
midrange.com
