>>>>>>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.

Try

? 0xFFFFFFFFffffffffffffffffffffffffff

You cannot cast it as integer, its to big. I guess, hex representation was created for any positive number VFP can handle. That would explain why we need minus sign in front of it to denote a negative number.