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