>>>
>>>Is there a reason that VFP's BINTOC() won't work for you?
>>
>>Unfortunately, the BINTOC() and CTOBIN() functions dont produce the proper chars. BINTOC() almost works except for two problems, the MSB order is reversed and the high byte is nonstandard. The first issue is trivial and easily dealt with, but the second is not. I looked at how VFP stores it's integers in a dbf and they don't match BINTOC(). Bummer. Perhaps the high order byte rule can be determined with some experimentation and the VFP functions used. I'll find out.
>>
>>Thanks for the suggestion.
>>
>>Gary Foster
>
>Gary,
>
>Both of these function invert the state of the most significant byte as well as the order. Positive numbers have what should be the most significant bit set (the mantissa), and negative have it cleared. This is because the purpose of these functions is for generating keys for tables and the way strings are evaluataed. The problem with FoxPro code that doesn't take the sign in account, is that FP stores all numeric values in memory as 8 byte floating points. Therefore, a function that's evaluating -1, for example (4 bytes all equal to 255) will return 4294967295. The solution is a function similar to what follows:
>
>
>FUNCTION Str2Int
>
>LPARAMETER pc_val
>
>LOCAL lnresult, lnlen, lni, lnmsb
>lnresult = 0
>lnlen = LEN(pc_val)
>lnmsb = (lnlen * 8) - 1
>FOR lni = 1 TO lnlen
> lnresult = lnresult + ASC(SUBSTR(pc_val, lni, 1)) * (256 ^ (lni - 1))
>NEXT
>* Test the mantissa
>IF BITTEST(lnresult, lnmsb)
> lnmax = (2 ^ (lnmsb + 1))
> lnresult = lnresult - lnmax
>ENDIF
>RETURN lnresult
>
>
>The above will properly handle signed integers.
>
>hth,

George,
I worked out a solution similar to yours and it works fine. I think that it's interesting that the bintoc() and ctobin() functions work differently than VFP's storage of 4 byte integers in a DBF, i.e., the inversions you mentioned above. I have my functions to create 2 and 4 byte strings from numbers and numbers from strings now. Thanks for the input.

Gary Foster