Hello Walter.

One that comes in mind is that when you bind the value to a numeric column and the control is not bound to anything (Controlsource = ""), the Value, sometimes is numeric, sometimes caracter. The other way arround also seems to be true. When it is bound to a column that contains character, but a numeric value, it sometimes is converted into numeric and sometimes to character.

I do not understand what you are trying to say here. Do you mean that the BoundColumn comes from a data source that is numeric but the combos's ControlSource is empty that the data type of the value changes? If so, I am sure that you know that the default value for the Value property is an empty string (i.e., character data). As you know, the value of a combo or list box is taken from the column of its internal list that is specified by its BoundColumn. Now, if the combo's BoundColumn comes from numeric data, it seems perfectly obvious to me that you must initialize the control's Value property to zero in the property sheet in order for things to be consistent.

While it is indeed true that the combo stores the data in its internal list as character data regardless of its original data type, setting BoundTo to true will automatically handle the conversion of the combo's value to the numeric data type.

If this is what you are talking about, this is not a combo box "issue". IMHO, this just comes down to understanding how the comtrol works < s >.

I've dealt with this issue more than once since VFP5. I now always set the controlsource to a character property to avoid the issue. Anyways, this is one bug that really irritates me.

And I almost always bind my combo boxes to an integer foreign key field. I bind to character data less than 1% of the time. I have never seen the bug that you are decribing, whether my combo's are bound to numeric data or left unbound.

Why can't the VFP team solve the situation in such manner that if the sparse property is set to .F. the combox' downarrow is not displayed in every row ?? sure a workarround does exists (And I use them a lot), but it still is a kludge that should not neccesary at all.

All you have to do is set the column's ControlSource up like so:

( IIF( SEEK( < RecordSource.ForeignKeyField >, '< LookupTable >', '< LookupIndexTag' ), LookupTable.Description, '' ) )

And set up your combo with any RowSourceType but 2-Alias or 6-Fields and populate it with the data from the lookup table. You can then leave the column's SParse property set at its default value (true). I do not understand why you think it is a kludge.