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

Well, if it did use a signed or unsigned integer, such a representation would have to generate an error.