Announcement

**Matthew Berg** · 25 Feb 2003, 10:53 AM

As the WIN32API.INC file provided by PowerBASIC has declarations for the %FALSE and %TRUE constants, you will be unable to create your own constants with these names unless you either don't use the standard WIN32API.INC file, or you modify the file provided by PowerBASIC.

To get around the problem of a conflict with the declarations of %FALSE and %TRUE constants in WIN32API.INC, and avoiding the need to modify the standard WIN32API.INC, I created my own macro's for FALSE and TRUE "constants", like so:

Code:

MACRO FALSE = 0
MACRO TRUE = NOT FALSE

I would like understand why the compiler believed

Code:

%FALSE = 0

was a syntax error?

%FALSE = 0 is not a syntax error - you may note that PowerBASIC's own WIN32API.INC also includes this same declaration.

DEFINT A-Z is the default type declaration in both the DOS and PBCC versions.

The DEFxxx commands have no effect on how constant values are stored. Don't forget that during the compilation process, the compiler will replace all instances of a constant's symbol (name) with the constant's actual value.

My first reason was because in some instances a TRUE-RESULT is returned as " -1 " (Old Crescent Tools approach) and would not test out correctly with the TRUE declaration in the "WIN32API.INC" file.

Ideally, you should never test the "truth" of an expression with the equals operator, i.e.

Code:

IF [i]expression[/i] = %TRUE THEN ...	' unsafe
 
IF [i]expression[/i] THEN ...
'or,
IF ISTRUE [i]expression[/i] THEN ...	' better

------------------
If you try to make something idiot-proof, someone will invent a better idiot.

**Michael Mattias** · 25 Feb 2003, 11:12 AM

Code:

#IF NOT %DEF(%TRUE)
   %FALSE = 0
   %TRUE =  1
#ENDIF

#INCLUDE Win32API.INC or not, your program will always have one and exactly one set ot %TRUE & %FALSE

(Although I think the compilers ignore duplicate equates as long as the value is identical).

MCM

**Tom Hanlin** · 25 Feb 2003, 02:13 PM

Also see the ISTRUE and ISFALSE operators.

------------------
Tom Hanlin
PowerBASIC Staff

**Matthew Berg** · 26 Feb 2003, 10:20 AM

#INCLUDE Win32API.INC or not, your program will always have one and exactly one set ot %TRUE & %FALSE

If you want to include WIN32API.INC into your program, and you want to "correctly" define TRUE to be NOT FALSE (0), then you are still going to have to modify WIN32API.INC or define your FALSE and TRUE values some other way (differently named constants, macros, etc.), regardless of whether or not you enclose your definitions in an #IF NOT %DEF( %TRUE ) / #ENDIF block.

Although I think the compilers ignore duplicate equates as long as the value is identical

I thought that was a feature only introduced with the latest versions of the compilers?

------------------
If you try to make something idiot-proof, someone will invent a better idiot.

**Michael Mattias** · 26 Feb 2003, 10:37 AM

thought that was a feature only introduced with the latest versions of the compilers

Wouldn't surprise me. There's always some "What's New" which does not appear in the "What's New."

It's a lot easier to just bite the bullet: copy the source, recompile with new compiler, and re-test, because you can get burned by some of the "Surprise What's New" stuff. (although now that is mostly limited to changes in the Windows header files).

Unfortunately, the re-testing is terribly tedious and quite expensive.

MCM

[This message has been edited by Michael Mattias (edited February 26, 2003).]

**Tom Hanlin** · 26 Feb 2003, 11:05 AM

"correctly" define TRUE to be NOT FALSE

In BASIC as in C, "true" is any value other than zero. Forcing it
to a specific value has some application under Microsoft BASICs,
which only have an arithmetic NOT operator. There's no real point
to it under PowerBASIC, with its ISTRUE and ISFALSE boolean tests.

...the compilers ignore duplicate equates as long as the value is identical
/ I thought that was a feature only introduced with the latest versions of the compilers?

No, it's not a new behavior.

------------------
Tom Hanlin
PowerBASIC Staff

**Roger Rines** · 26 Feb 2003, 12:11 PM

This was an informative question for me; Thanks to all who responded.

Here is what I’ve learned and done:
My Old DOS programs were running well using the logic:
CONST FALSE = 0, TRUE = NOT FALSE

In MS PBS7.1 & QB4.5, an equal comparison returns a value of “ –1 “ and when I looked at the “WIN32API.INC” it showed that %TRUE was being assigned a value of “ 1 “. This thinking will almost certainly cause a problem.

There are a lot of instances where the word TRUE is used in the old programs and I didn’t want to fix more than was necessary to move them to PBCC30 by rewriting logic in areas that I didn’t want to test thoroughly. This motivation drove me to ask the question and my thinking is based on converting old programs only.

To accomplish a minimual change goal, I’ve taken the suggestion Michael Mattias offered with his:

#IF NOT %DEF(%TRUE)
%FALSE = 0
%TRUE = 1
#ENDIF
This logic is what is now in my “WIN32API.INC” file and allows me to pre-define the Equates ahead of the INCLUDE line as follows:

' Constant/Equates Preferences
%FALSE = 0
%TRUE = NOT %FALSE

$INCLUDE "WIN32API.INC"

This should give me the ability to keep the logic consistent for my old program migration without destroying whatever logic inspired the approach written in the supplied “WIN32API.INC” file.

After reading Mathew Berg’s response, I’ve decided the functions:

ISTRUE & ISFALSE

are better approaches for conditional test, and I’ll begin using them for new code and will look at existing code to see if they would improve the reliability of what I’m using. I had seen these functions in the listing before, but never gave them the importance they have until I read the responses here.

As to why I was getting a syntax error for “%FALSE = 0”, I’ve discovered it was from where it was placed in the code. I had it too far down in the declaration area and have now learned it must be placed early.

Nobody showed any strong feeling about whether “WIN32API.INC” should be left out or not. Telling me it is just a matter of what I’m trying to accomplish and use for functions that makes the file useful or not.

Thanks again for the responses. I seem to learn a lot each time I read the postings in these forums.

------------------
Roger...
(Mail to rdrines at SpamCop dot Net)

[This message has been edited by Roger Rines (edited February 26, 2003).]

**Jonathan Berry** · 26 Feb 2003, 01:19 PM

PRINT (2+2=4)

returns -1
Aside from hiccups that might arise with unsigned integers, are there problems with the hoary truth that
true% = -1 (in 2's complement notation) ?
true% = -1 also handles binary and boolean expressions without the need for new keywords.
Am I just old-fashioned, or have I missed something?

------------------
Jonathan Berry
[email protected]

**Eric Pearson** · 26 Feb 2003, 01:36 PM

Jonathan --

> Am I just old-fashioned, or have I missed something?

No, on both counts.

I agree with you, because if FALSE is "all bits off" then TRUE must be "all bits on". And if you use the most efficient 32-bit numeric variable type -- a LONG integer -- "all bits on" corresponds to negative one. Using %TRUE=-1 allows you to use (IMO) much more logical statements in your source code. For example it allows you to use the NOT operator in things like IF NOT X THEN... where X is set to TRUE or FALSE. And lots of other nice, logical things.

But there are two (related) problems with that. Unsigned integers such as DWORDs can't store the value negative one. The best they can do is set all the bits on and see which numeric value comes out. So if you are using a DWORD then TRUE is &hFFFFFFFF and if you are using a WORD then TRUE is &hFFFF... see the problem? We don't want to have multiple definitions for TRUE or other types of comparisons like IF X = TRUE become very complicated.

So the other common way to define TRUE is positive one. All signed and unsigned numeric data types can store positive one, so there is no question what TRUE means.

The second problem is that regardless of all of the above, the Windows API defines TRUE as positive one. That's probably because of the large number of unsigned integers that are used by the API.

So you are free to define TRUE any way you please in your programs, but if you use a Windows API function and MSDN says that you must use a TRUE value for a certain parameter, it almost always means positive one. (Some APIs allow you to use any nonzero value for TRUE, but there is no such thing as X = ANYNONZEROVALUE in PowerBASIC or any other language.)

Personally, when I download a new WIN32API.INC file the first thing I change is this:

Code:

%FALSE    =  0
%TRUE     = -1
%API_TRUE =  1

But I don't mean to say that I am right and the WIN32API.INC file is wrong. Remember, the purpose of WIN32API.INC is to define a large number of values the way the Windows API defines them. But being stuck in my ways I prefer %TRUE=-1, and I am capable of remembering which equate to use when I call an API function.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited February 26, 2003).]

**Jonathan Berry** · 26 Feb 2003, 03:46 PM

Eric:

Thank you. Brilliant. I'm saving that.

But I am old-fashioned. I don't use unsigned integers or the Windows API, though I can foresee the day when a pair of muscular arms will emerge from the screen and drag me, kicking and screaming ...

------------------
Jonathan Berry
[email protected]

**Eric Pearson** · 26 Feb 2003, 03:58 PM

No, it will probably be more like a faint, seductive whisper saying "Jonathan... Come toward the light, Jonathan..."

Seriously, the ability to use the Windows API represents tremendous power in a PowerBASIC program, and you will probably want to use it eventually. There are many native functions built into Windows, and it's hard to tell which ones you will find most attractive. Date manipulation functions, functions for communicating between programs, low-level memory-management functions... literally thousands of different APIs are available. And when people realize that "an API is just a function" they discover a whole new world of "PowerBASIC extensions" just waiting to be mined.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

**Al Lawrence** · 27 Feb 2003, 02:22 AM

"Seriously, the ability to use the Windows API represents tremendous power in a PowerBASIC program, and you will probably want to use it eventually. There are many native functions built into Windows, and it's hard to tell which ones you will find most attractive."

Is there a reference somewhere out there to all the Windows APIs?

------------------

**Eric Pearson** · 27 Feb 2003, 04:11 AM

Al --

> Is there a reference somewhere out
> there to all the Windows APIs?

More than you could read in a lifetime.

For basic information on the "core" APIs you can download the Win32.HLP file from the PowerBASIC files area. It is a very useful quick-reference guide.
http://www.powerbasic.com/files/pub/mstools/

For the most current information on every single Windows API function, the MSDN (Microsoft Developer's Network) web site is your best bet. It's free, but IIRC you can pay a fee to get advanced features. The basic site is plenty for most developers. Start here:
http://msdn.microsoft.com/default.asp

To look up API information, here is the MSDN Search Page that I like best:
http://search.microsoft.com/advanced...?siteid=us/dev

The MSDN "Knowledge Base" (which is not searched by default) is a huge repository of bug reports, how-to articles, topic overviews, and many other goodies. MSDN even includes the contents of many different books, in their entirety. And programming-related utilities that you can download, and lots more.

Be careful, because in addition to information about Windows 95/98/ME/NT4/2000/XP, MSDN contains information on Windows 3.1, Windows CE, and other less-mainstream versions of Windows. When you read an MSDN article it's always a good idea to read the "applies to" information first.

When you find an API that you want to use in a program, use the PowerBASIC BBS's Search feature to find messages containing the appropriate keyword. For common APIs the chances are pretty good that you will find some ready-to-use PowerBASIC source code here.

Oh yes, if you prefer dead trees the BBS's FAQ Forum has a list of popular reference books.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

**Al Lawrence** · 27 Feb 2003, 08:08 AM

Many thanks for the advice and pointers!!!!

------------------

**John Lee** · 27 Feb 2003, 08:19 AM

Use ABS() will always return a positive number.

Regards

------------------

**Jonathan Berry** · 27 Feb 2003, 09:45 AM

Originally posted by John Lee:
Use ABS() will always return a positive number.

Regards

I hope that ABS () always returns a non-negative number.

Expanding on Eric's
API_TRUE = 1
you could also define WORD and DWORD versions of true% = -1
W_TRUE?? = -1
DW_TRUE??? = -1
do in fact (with whatever the default error checking settings are) return the desired values:
65535 4,294,967,295 (after you FORMAT$ ...)

and
test?? = (2+2=4)
print test??
returns 65535, which is binary 1111111111111111, as desired.

Although I'm not sure it has a practical application, one could do some binary logic with unsigned integers.

------------------
Jonathan Berry
[email protected]

**John Lee** · 27 Feb 2003, 04:16 PM

Jonathan,

>I hope that ABS() always returns a non-negative number.

Why only hope ? Any experience it is not ?

Regards

------------------

[This message has been edited by John Lee (edited February 27, 2003).]

**Lance Edmonds** · 27 Feb 2003, 05:47 PM

Jonathan was simply correcting the terminology being used, he is not talking about bugs.

That is, the phrase "ABS() returns a non-negative value" is technically more accurate than saying it "returns a positive number" as the latter might imply the return value will be greater than zero, whereas ABS() can return zero or greater.

Therefore, technically speaking, zero is neither a positive nor a negative number... see SGN().

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**John Lee** · 27 Feb 2003, 08:24 PM

Lance,

I believe positive number including "zero".

PBDOS 3.5 Reference Guide Page 36
ABS FUNCTION Remarks
The absolute value of a number is its positive value........

I understand that
(PBCC2 Page 135 "The absolute value of a number is its non-negative value.")

Regards

-----------

[This message has been edited by John Lee (edited February 27, 2003).]

Announcement

FALSE & TRUE as CONST

FALSE & TRUE as CONST

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment