>>>>>My best guess is that the key is defined as a signed 8-bit integer, and when treated as a UCHAR, is represented by the value 0xFF
>>>>
>>>>Yep, I'd guess so. I think, as I mentioned in my other post to Sergey, that VFP interprets hex values as unsigned unless otherwise specified. Thus, -0x00000001 makes some sense.
>>>Actually, VFP has representational problems at and above 0x80000000 - it'll convert it internally to a real, which is why I now recast hex value using BITOR() internally in ClsHeap as of the last released version. You can test this easily enough; try the following:
>>>
>>>

? 0xFFFFFFFF = -1
>>>? BITOR(0xFFFFFFFF,0) = -1

Don't you mean

? 0xFFFFFFFF = 4,294,967,295

cause that's what I get in VFP 6.0 and 7.0.
>
>Yes, but try passing that to a DLL as an INTEGER parameter and see what happens...

Ed,

Just a couple of more thoughts on this.

I find it surprising that VFP would cast the hex representation of a number as anything other than an integer. However, that seems to be the case (it appears to be a real). The snippet above seems to indicate that VFP always casts integers as being signed. Further, in 7.0, using the AS Integer clause in the scope declaration apparently has no effect.

This also explains the use of the following:

* Registry roots
#DEFINE HKEY_CLASSES_ROOT           -2147483648  && BITSET(0,31)
#DEFINE HKEY_CURRENT_USER           -2147483647  && BITSET(0,31) + 1
#DEFINE HKEY_LOCAL_MACHINE          -2147483646  && BITSET(0,31) + 2
#DEFINE HKEY_USERS                  -2147483645  && BITSET(0,31) + 3

in the registry class. I always wondered why they didn't use hex instead. Now I know.