>>>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..
Internally, I think they are a packed format of some sort; it's a matter of how VFP casts things sent outside of VFP that creates the large integer issues, since VFP has to cast the internal representation into a format acceptable by the interface. This is a source of lots of problems related to passing arrays of numbers through a COM interface, because VFP has to make the decision of how to identify and pass the parameter; an array passed via a COM interface will likely be viewed as a SafeArray of variants, which will gwt converted after crossing the VFP/COM boundary; if the receiving COM component expects a SafeArray of integers, and VFP has represented things as reals in the variants, things can get ugly, and VFP would represent 0xFFFFFFFF as a real.
>
>Exactly the direction where I would dig into if/when I'd have this problem. But then, knowing this can happen, I'm not even walking into that direction if I can avoid it... and did that with success so far.
>
>Don't know how this helps Steve, though, because these large negative integers seem to be there for some other reason, so I don't know if he's allowed to replace them with some tame numbers.
>
>BTW, I thought VFP was keeping N type numbers with more than 4 bytes internally, since its precision is 15.5 significant digits. Or is this conversion of long integer into short real taking place only in some special cases?
