Hi Marcia,

>No matter with what I initialize the value, it sometimes changes. It changes from character to numeric or the other way arround. I've found that initializing it to character is the most reliable, however occasionally I find instances where it 'randomly' converts to numeric again. Now this is AFAIK only happening when you don't specify a controlsource.
>
>As I said, I have never experienced this problem. You should come up with an example to reproduce this bug and send it to the VFP team. I am sure that, if they can reproduce it, they will be able to fix it.


So far, I was not able to reproduce the problem in a simple case. It all occured in a live production database, from which I was able to draw the conclusion. I don't have a clue to the EXACT conditions this to occur, except that if I bind it to a property or controlsource it does not occur.

>I do this sort of thing pretty frequently and, as I have already said, I have never experienced the problem that you are describing. Maybe I am just lucky < s >.

There must be something I do different then...

>However most of my comboboxes are populated from an array property on my combobox baseclass.

>When setting up the controlSource like this, it does not matter how the combo box is populated. One would very reasonably assume that if you are storing a foreign key in a table, it points to a description that is stored in some lookup table somewhere. Maybe I just took my stupid pills today, but I still do not see the problem.

Nope, not always.
1. Sometimes they are hardcoded lists, in which case you have additional work to do after the REQUERY() (e.g. a combobox containing sex (Male and Female))
2. sometimes the list is a complex expression which originates from a complex SQL command or other calculation. Of course you can store the result in the cursor, index it and use that.
3. When doing Client/Server this also becomes more of a headache for the same reason as 2 and you cannot SEEK() into a table: You'll have to do cursors.
4. When using dynamiccurrentcontrol, this really becomes a nightmare.
5. You might not have an index on the field.

I've not used your proposed strategy often (maybe once or twice), but my experience in using grids and comboboxes says you don't want to use too many tricks. The grid itself is full of certain bugs you'll have to workarround and I don't want to intruduce to many extra risks. And if you say you don't have experienced problems with this approach, I'll be the last not to believe you, but my experience with grids (that might exceed even yours (see the 10 or so grid bugs in VFP 8 I've submitted)) say you want to keep it simple if you can.

Also forcing everything to be seekable in a cursor or table for me is at least as troublesome as many of the arrays populating the combobox are comming from business objects, so I can't directly use the same source where they came from. Also this is a matter of abstraction. the array might be populated from a table, or it might not.

>So I use views which have also the meaningfull value, which populates the column and the integer field which populates the integer field. When you change the combobox value, the comobobox class automatically writes the displayvalue in the character meaningfull field.

>I, too, have such a combo class. I use it when I must allow the users to add items to the combo in the grid on the fly. As I am sure you know, you cannot use the trick of setting up a conditional RowSOurce because that makes the column ReadOnly and that does not allow you to change the value in the DropDown Combo ( style = 0 ) that it contains < s >.

I've got lots of those comboxes in a recent application. Adding values on the fly, even within a grid. Anyways, I've found that using binding a combobox to an array property (on the same combobox) deals with the vast majority all situations I have to deal with. I don't have to think, test and debug etc.

Walter,