Why is the value of %True equal to +1 and ISTRUE(1 = 1) eqaul to -1 ?
Because ISTRUE returns a boolean value (+1 or -1), whereas %TRUE is a constant that can be defined to any value excepting 0.
Actually ISTRUE returns -1 if the expression is true and 0 (zero) if the expression is false. (See the truth table in the PowerBasic help file).
%True is defined elsewhere in FireFly or PowerBasic. Its value is +1. It would make more sense to me for %True to have a value of -1 to be consistent with ISTRUE.
I can deal with the issue but I'd like to know the reason there is a different value for TRUE.
Hi Rhody,
I asked exactly the same question as you some times ago.
Look at this thread on the PowerBASIC forum:
http://www.powerbasic.com/support/pbforums/showthread.php?t=39619 (http://www.powerbasic.com/support/pbforums/showthread.php?t=39619)
I'm pretty sure you'll find some interesting answers.
Jean-Pierre
Thanks for the link.
What a waste of discussion time and effort for something that should be standard. For me it has been a source of bugs within my application. Especially with the transition of the application from VB to FireFly. I can deal with it but how many others are having to deal with it? How much time and effort wasted? How many bugs in applications that should not be there? All because we cannot standardize the definition for True and False. Senseless and frustrating. Wonder if the definition is standardized in the Apple and Linux worlds?
In his infinite wisdom, M$$$ did choose -1 as TRUE for VB and +1 for C. The Windows API headers are in C, so TRUE is +1 when using anything related to C (both in Windows, Unix, Mac or whatever). ISTRUE will always return -1 if the argument is not 0, contrarily to NOT.
If this is a problem for you, there is a very easy solution, just use -1 instead of %TRUE, or define your own constant, e.g. %MyTrue = -1.
This inconsistency stems from the fact that, traditionally, boolean values have always been either zero or non-zero, which opens up a bit of a gray area, as you've noticed.
It's a simple fix, though... just test for the above "zero or non-zero."
if ( value <> 0 ) then
(code for true case)
else
(code for false case)
end if
OR
if ( value = 0 ) then
(code for false case)
else
(code for true case)
end if
Sometimes it's easy to over-think the plumbing.
Lots of ways to work around the issue such as your example with IF statements and use of ABS with calculations. For example,
A = B + ABS(X > Y)
But it's just another source of bugs that should not be there.
I've always just thought of %False = 0, and %True = NOT(%False). When expecting a true/false value, I've always used ISTRUE/ISFALSE. If I must test for a numeric value, it's either = 0, or <> 0
In Basic, NOT is a boolean operator, whereas in C, the ! operator is logical.
* Any non zero operand value is treated as 1.
* The result is 0 if the operand is not 0.
* The result is 1 if the operand is 0.
! 0 = 1
! 1 = 0
! -1 = 0
! 15 = 0
The Windows API has been written in C, not in Basic, therefore it uses 1 for True.