A question according to "%True, %False"

[norbert doerre]

PBWin9 help file references a function

TrueFalse = ISFILE(FileName$)

Remarks
The file subsystem Is checked To determine whether the file Or directory specified by FileName$ currently exists. If it Is found In Any form (hidden, system, Read-Only, etc.), the value true (-1) Is returned. Otherwise, the value false (0) Is returned.

But using %TRUE and %FALSE constants gives back 1 = %True and 0 = %False.
So, values TRUE and FALSE have each two different definitions in PB.
Why that?

[Michael Mattias]

You should aways be testing for true/false with ISTRUE() and ISFALSE().

Example code should read...

TrueFalse = ISFILE(FileName$)
IF ISTRUE (TrueFalse) THEN 
   do what you do when file exists 
ELSE
   do what you do when it doesn't. 
END IF

Or more simply

IF ISTRUE ISFILE(FileName$) THEN 
   do what you do when file exists 
ELSE
   do what you do when it doesn't. 
END IF

You should not test a "true/false" (PB or WinAPI) for equality against %TRUE or %FALSE.

Now you don't care what the values of %TRUE or %FALSE are, as long as %FALSE equals zero and %TRUE doesn't.

MCM

[norbert doerre]

Question to TRUE FALSE is still a question.

Following code simply compares to -1 as true.
Function does nothing because the file actually exists.

If IsFile("mcWheel.dll") <> -1 Then 'file exists and result = -1
KillProcess(GetCurrentProcessId()) 'proc is not killed
End If

But using IsFalse(IsFile ...

if IsFalse(IsFile("mcWheel.dll") ) then 'process is killed
KillProcess(GetCurrentProcessId()) 'proc is killed
End If

... the result becomes obviously false with IsFalse() and the
process is killed even if IsFile("mcWheel.dll") returns -1.

[Michael Mattias]

>If IsFile("mcWheel.dll") <> -1

What did I just say about testing true/false functions with equality? (Hint: I said, "don't do that.")

Your application is simple to code:

IF ISFALSE (ISFILE(filename)) THEN  ' if file does not exist 
   KillProcess....
END IF

If you can get past "equality tests," ISTRUE() and ISFALSE() make programming really easy and the resulting code understandable and maintainable.

Oh, you want me to deal with your question as written anyway?

OK.

%TRUE and %FALSE are equates; True and False are concepts.

ISFILE() returns true or false, not %TRUE or %FALSE, so use ISTRUE() and ISFALSE() to test the return.

Scr^h^h^hEschew the help file on this one.

MCM

[William Burns]

In programming, the general rule is FALSE always equals 0 and TRUE can equal anything that is not 0. So TRUE can be any positive or negative number. (that's why definitions for TRUE do not always match)

So, like MCM said, never test for an exact value to find TRUE. Instead use the ISTRUE/ISFALSE functions, or if you must, you can test if it does or does not equal FALSE (0) since that will not change.

[Mel Bishop]

In programming, the general rule is FALSE always equals 0 and TRUE can equal anything that is not 0.

To expand a little, TRUE/FALSE can be any different numbers.

TRUE = 643224
FALSE = 938573

Perfectly acceptable, as long as you use ONLY these values in your program.

[William Burns]

To expand a little, TRUE/FALSE can be any different numbers.

TRUE = 643224
FALSE = 938573

Perfectly acceptable, as long as you use ONLY these values in your program.

I would have to disagree or at least clarify. Yes you can use any values you want as long as you are returning the value and you are the one checking it. But if you try to use a "standard" function like ISFALSE it will only work correctly if FALSE is equal to zero. (0)

If you think about FALSE using zero, it makes perfect sense. Because all electronics (like computers) see numbers as binary on a low level which is ones and zeros. Think of them as switches, 1 being on and 0 being off. So 0 is the only number where all binary positions are all zeros/off. Any other number has at least one position on/true. Hopefully this doesn't confuse people more, but it made sense to me since I also dabble in electronics.

[Knuth Konrad]

As William explained, you have to start "somewhere". And then continue to apply boolean logic:

Axiom: FALSE = 0

And then: TRUE = NOT FALSE.

So anything <> 0 is TRUE. While of course 2541.45 is TRUE in this sense as well, when it comes to defining a constant for TRUE, a more intuitive value like 1 (think: "ON") or -1 (all bits set to 1 and the leading bit interpreted as the signing bit, think: "ALL ON") does make more sense.

And the 1 vs. -1 is often just a language/data type issue (all bits on and signed vs. unsigend integer used to store the constant).

[Eric Pearson]

Norbert --

For lots more information (and opinions) about True and False, see these threads about this same topic:

http://www.powerbasic.com/support/pbforums/showthread.php?t=31668

http://www.powerbasic.com/support/pbforums/showthread.php?t=16018

http://www.powerbasic.com/support/pbforums/showthread.php?t=9146

-- Eric

[norbert doerre]

Eric,
thanks for your links, but from Germany they seem not to be available.
My question with true/false has nothing to do with understanding it.
The problem i found out here is a quite mysterious one. It reveals a logical
inconsistancy with using true/false as a function result.

the file below "mcWheel.dll" really exists and
- IsFile("mcWheel.dll") - gives correctly back -1 as true.

But using - IsFalse(IsFile("mcWheel.dll") - results also in true.

This leads to an unwanted execution of the following code:

if IsFalse(IsFile("mcWheel.dll") ) then 'should only be executed if - IsFile("..") - is false.
KillProcess(GetCurrentProcessId()) 'process is killed even if - IsFile("..") is true.
End If

Perhaps somebody has an idea?

[John Gleason]

The file C:\SCANDISK.LOG does exist.

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG

'- IsFile("mcWheel.dll") - gives correctly back -1 as true.

'But using - IsFalse(IsFile("mcWheel.dll") - results also in true. << not for me in below code

'This leads to an unwanted execution of the following code:        << not for me in below code

IF ISFALSE(ISFILE("C:\SCANDISK.LOG") ) THEN 'should only be executed if - IsFile("..") - is false.
   ? "This never gets displayed for me"     'and that is what happens for me, this does not get executed.
END IF


END FUNCTION

[norbert doerre]

John,

i can't help using:

If IsFile("mcWheel.dll")) <> -1 Then
KillProcess(GetCurrentProcessId())
End If

This is running OK for me here.
My code is a larger DLL with 116 kb compiled code which cannot be run in debug mode with PB debugger. It cannot be executed as an exe file, too. So i only can use my always included debugwin.inc to give back some variable results.
I hoped that some others in the forum could send some of their experiences with such a phenomene. They happen very rarely, however, and, after some time, there is always a solution.
Thank you for your interest!

[Michael Mattias]

Off topic but...

If IsFile("mcWheel.dll")) <> -1 Then
   KillProcess(GetCurrentProcessId()) 
End If

I don't know what the procedure KillProcess() does (code not shown), but If this is your own process (GetCurrentProcessID) I hope it is calling ExitProcess(), not TerminateProcess().

ExitProcess() is far more 'orderly' in nature. See your API doc for details of both.

MCM

[Michael Mattias]

A long time ago I was coached to avoid testing for false, because it's easier for the next poor schlub to understand...

IF Condition is True THEN 
  do stuff

... than to understand....

IF Condition is False THEN 
    do stuff

.. so I always look for ways to test the affirmative.

But that's just a style thing, although I do have to stop to figure out....

 IF ISFALSE (ISFILE(x)))

... which is, "If it's true that it's false that it's true X exists."

What is NOT style is using NOT with false....

 IF NOT ISFALSE (condition).....

YUCK!

MCM

[Cliff Nichols]

How about something as simple as

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     SELECT CASE ISFILE(FILENAME$(1))
          CASE %FALSE
               MSGBOX "Its Not a file"
          CASE <> %FALSE
               MSGBOX "Its a file"
     END SELECT
END FUNCTION

[Michael Mattias]

How about something as simple as

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     SELECT CASE ISFILE(FILENAME$(1))
          CASE %FALSE
...

That tests true and false for equality. I believe I suggested that is 'less than optimal.'

[Chris Holbrook]

How about something as simple as

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"
FUNCTION PBMAIN () AS LONG
     SELECT CASE ISFILE(FILENAME$(1))
          CASE %FALSE
               MSGBOX "Its Not a file"
          CASE <> %FALSE
               MSGBOX "Its a file"
     END SELECT
END FUNCTION

Cliff, if you are looking for simple then why not just

#compile exe
function pbmain as long
    if isfile(command$(1)) = 0 then s$ = " not"
    msgbox "Its" + s$ + " a file"
end function