>>>Or is it just displaying it the wrong way? Try to Set Decimals to 10 or so, and see if it's just the visual representation that's wrong.
>>
>>
>>Hello again. Thanks for trying to help me here. I tried what you said, "setting decimals to 10" and it still will not work. There seems no way to bind this a VFP combo control to an integer field. Anyone else out there have a work around?
>
>I use integers in combos all the time, but then the rowsource is practically always fields, i.e. "alias.displayfield,integerkey", and these integers are usually small and surely not negative. I wonder if large negative integers may somehow be out of scope for Fox? I assume the definition of large would be "negative with the 31st bit used". This is not the only place where VFP's definition of integer as "signed 32-bit integer" doesn't really work; it's also when you try to use some APIs which need large unsigned integers (with 31st bit set) that we have problems.

You've got it - VFP's internal integer type is a signed LONG, not a ULONG, so values >2^31-1 in a ULONG are shown as a negative number, and integer numeric values 2^31 and greater are actually stored as an N datatype. This is why I added recasting code using BITOR() to ClsHeap in the last revision, so that passing a value of 0xFFFFFFFF as an INTEGER parameter to a DLL didn't smoke API calls on some OS versions. The range of values supported internally as an integer in VFP range from -2^31 - 2^31-1.

If very large integers are encountered and encoded as reals, they may not be represented internally as an integer value, only as the closest real approximate value in a 4 byte real. As numbers get larger, an entire range of integer values may end up being represented with an identical real - the integers are indistinguishable in a 4 byte real (the numbers supported are larger for a DOUBLE.)

Take a look at the comments in ClsHeap for a more detailed explanation of the representation and conversion..