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

Ah, I see what you meant. Missed it the first time. Sorry, but no shubbery this time.:-)