Handles in Win NT and 2000 ?????

[Chris Boss]

I have a question:

Developing for Win 95,98 I have always assumed that handles returned by Windows (ie Font handles) are always positive numbers (non-zero, non-negative).

My question is:

On Win NT and 2000 can the handles returned be a negative number (at least for Fonts) ?

I would think that if Win 2000 were to use the entire 32 bits for a handle (95 uses 16 doesn't it) and if it was treating it as a DWord rather than a Long, then the bit which makes it negative could be set.

Are handles Longs or Dwords ?

Should I always use a DWord for handles ?

The Win32api.inc file I have uses a Long for the return value for CreateFont. Has this been chnaged to DWord for Win NT and 2000 ?




[This message has been edited by Chris Boss (edited January 23, 2000).]

[Chris Boss]

I think this answers my question:

http://support.microsoft.com/support.../Q229/0/72.ASP

I wonder "how many" API functions that used Longs in Win 95,98 will now require DWords in Win 2000 ?

This could cause some problems if a value uses the bit that sets a value to negative.

[Chris Boss]

Yes !

I have had this verified by one of my Beta testers.

I was having some problems finding a bug dealing with Font handles with Win NT and 2000 and guess what the cause was ?

I had a simple line of code witha comparison:

hFont=CreateFont(....)
if hFont>0 then
    ' save the font for later use
end if

Notice I "assumed" the Font handle would be positive in value and so I used > 0 rather than <> 0 in the comparison.

This was the "problem" !

Win NT 4.0 and Win 2000 can use "every" single bit in a 32 bit value for Handles. If you are writing code using the current Win32api.inc files, you will be returning fonts to a Long variable, rather than DWord . (I use PB 5.0 and CreateFont returns a Long according to inc file)

Win NT and 2000 must be using DWords Internally and if you get a handle back and it is returned as a long, the handle "may" be a negative value.

This means that if you write code that does a comparison to see if the font is a valid handle (API says NULL returned if failed) , always use <>0 and never "assume" that the handle is positive like I did.

[Lance Edmonds]

I have always used:

IF ISTRUE handle& THEN...

Which averts this problem, and is visually "tidier" then <> 0 (IMHO!)

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

[Patrice Terrier]

You can also just use

IF hFont& THEN

this will work either...


-------------
Patrice Terrier
mailto[email protected]pt[email protected]</A>

[Lance Edmonds]

Patrice is correct - his example performs an implicit ISTRUE, therefore is functionally identical to my suggestion above.

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

[Eric Pearson]

One small point... If you use Patrice's method to test for a nonzero value:

IF hFont& THEN

...it is very efficient and very fast, but when you're writing (or re-writing) code you have to keep in mind that you can't do this:

IF NOT hFont& THEN

If hFont& is a nonzero handle value, then "NOT hFont&" will virtually always return a nonzero value too. Lance's technique has the advantage of being NOT-able (I may have just invented a new word.) So unless you use a remark in your source code to document Patrice's technique and remind yourself (and other people that might work on the code in the future) that you are not testing for a Logical True (-1) or False (0) value, the ISTRUE/ISFALSE technique might be "safer" in the long run.

-- Eric

-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Chris Boss]

Well Guys, call me old fashioned, but

if hFont<>0

is just fine for me !

The code tells me:

that hFont is NOT equal to zero

I am not checking for true or false but I am checking for is NOT equal to zero. While technically it doesn't make a difference, it does help me in reading my code later, since I know "what" I was checking for.

My programming style is:

Only use a True or False check if the variable was used as a flag.

If the variable is used for a "Value" (which if Null means an error or failed function) I always check for "acceptable" values.

My problem was, I "assumed" that the handles would always be positive, so an error slipped into my code because I used >0 rather than <>0 .

If there is one point I would like to make is:

Handles can be negative on NT and 2000.

[Eric Pearson]

Chris --

I guess I did drift a little off-topic... {G}

> Handles can be negative on NT and 2000.

Definitely. In fact, the Windows API uses a standard value called %INVALID_HANDLE_VALUE which is defined as negative one in the WIN32API.INC file. That means that any variable which is used to hold a handle value may be asked to hold -1 if an API function fails. So (IMO) you should always use LONGs for handles, because DWORDs can't be used to hold negative numbers.

> Are handles Longs or Dwords ?

> Should I always use a DWord for handles ?

Technically speaking, you can use DWORDs if you're not worried about detecting INVALID_HANDLE_VALUE. When you pass a handle to an API you are actually passing a pointer to the location of a 4-byte block of memory, and the API does not really care how you handle it in your program. You could even use a 4-byte fixed-length string if you wanted to, and Windows would not care. As long as it was at least 4 bytes long. All Windows sees is a 4-byte pattern of bits. If you decide to use a DWORD and Windows assigns INVALID_HANDLE_VALUE to your variable, your program would see it as %MAXDWORD (positive 4.2 billion), which has the same bit pattern as a LONG with a value of -1. Or you could use a 4-byte string and your program would see it as CHR$(255,255,255,255).

When you're choosing a data type to use for a handle, the most important thing is how your program needs to use the value. But IMO using a LONG is the most logical choice.

-- Eric

-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited January 24, 2000).]

[Chris Boss]

Eric;


Very "informative" !!!!!

Thanks !!!

I see the value in sticking with Longs for handles. To Windows it is just 4 bytes, so it doesn't really matter.

I read somewhere that in 16 bit windows, some programmers would actually "truckate" the value done to 16 bits. MS warned that such practices were "dangerous" in 32 bit windows.

Windows 95,98 must not use all 32 bits like NT and 2000. The error I had in my software only showed up on NT and 2000.

[Eric Pearson]

> Windows 95,98 must not use all 32 bits like NT and 2000.

Windows 95 and 98 are limited to a system-wide total of 16,384 handles so I suspect that they are handled internally as two-byte blocks of memory (WORDs or INTEGERs), so a PowerBASIC LONG would see the bit patterns as positive values from 1 to 16,383.

-- Eric


-------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited January 24, 2000).]