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

Let's be a little more realistic. VFP supports a native datatype that's equivalent to a C int; the hex representations commonly passed as integer arguments across a DLL or COM interface may be DWORDs or UINTs. Examine the data types available to the DECLARE...DLL interface to see what I'm talking about. I frequently have to deal with parameters that are 64 bit integers, which I create in static memory or pass as a string; there's a need for this datatype fairly frequently in the Platform SDK, especially when talking about disk space or pointers in the 64 bit computing environment. Native VFP doesn't support a UINT natively, so you need to cast it using BITOR() in many cases.

In your example, even a DOUBLE will not render the value displayed accurately or uniquely; there is a significant range of hex integer values that will translate to an equivalent DOUBLE because of precision issues. The closest mechanism provided entirely native to VFP for this type of large integer representation uses a string to hold an embedded array of char that the recipient will interpret properly.

Issues of precision and accuracy in numeric representations will remain an issue in VFP with very large integer or real values, or very small reals as they approach zero.

If you aren't involved with non-VFP interface issues, it's no big deal; talking to things outside the VFP environment, or inside VFP near the cusps of precision in representation do present problems.