>We are experiencing a problem with unbound comboboxes that have a numeric value. Apparently, a combobox has a limitation of 10 digits for a numeric value. If the combobox has no ControlSource, and a value longer than 10 digits, VFP somehow converts the RowSource value to another numeric value entirely that is never more than 10 digits long. In addition, sometimes this is a negative number. However, a given RowSource value greater than 10 digits in length is always converted to the same value, so VFP must be following some sort of algorithm to do this conversion.
>
>On the other hand, if the combobox is bound to a numeric ControlSource, VFP truncates the value to 10 digits but the last 6 digits are all zeros. So, in the latter case, the value is still wrong, but somehow the combobox knows how to update the ControlSource with the correct numeric value. So as long as you inspect the underlying cursor, and not the .VALUE property, you are okay.
>
>To reproduce this you must have a combobox with a numeric RowSource, BoundTo set to .T., no ControlSource, and the Value property of the combobox set to a numeric value by default (we have been using 0). This behavior has been reproducable using RowSource types of both 2-alias and 5-array. The BoundColumn must contain a numeric value with more than 10 digits. We saw the behavior in VFP 6 and 7.
>
>Any ideas on what might be causing this? Any fixes or workarounds? Thanks in advance!
>zahid

Zahid,
With numeric data if you initially set value to 0 then value is an integer between -2147483648 and 2147483647. 10 digits come from that. However you could still use greater values if you use val(list(listindex,colnumber)). If your rowsource is alias,fields or SQL better directly use rowsourcetablename.fieldname.
If you initially set value to 0.0 (letting VFP understand it's not an integer) then you could directly use value or setting it to none (default) val(value).
Cetin