>I have a combo control whose rowsource is a table field. It exhibits the following rude behavior.
>
>Suppose I use the combolist (not the editbox) to choose value x. Fine.
>
>Then, prior to leaving the combo, I manually type value y (a legal value) and it is accepted. The ENTER that registers value y invokes a VALID which checks for hunkydoriness, refreshes the form and then returns .T. so that focus moves to the next control in the tab order.
>
>Fine.
>
>At this point, I can use the debugger to verify that mycombolist.value = y. mycombolist.listitem points to y. Furthermore, a perusal of all of the mycombolist's properties shows absolutely no reference to the numeric value of x nor are there any properties that contain a character string representing the value x.
>Additionally, recno() corresponds to the record having value y.
>
>No sign of x....then I simply use the mouse (or backtab) to reset the focus to the combo field......
>....and Voila! .... X !!!!!!!
>
>I have tried everything I know to catch VFP setting the combo value back to x...to no avial. Trapping on a change of mycombolist.value doesn't work. Trapping on a change of recno() doesn't work (even though the associated table pointer does change!)
>
>Totally frustrating!
>
>I feel I am being sabotaged by yet another example of undocumented, hidden behavior of a VFP baseclass but have no clue as to what is going on.
>
>Any help would be greatly appreciated.

One other clue is that event tracking shows that mycombolist.text1.gotfocus is executing, and it appears to be that this event method is culpable for reverting the editbox's value back to 'x'. text1 is apparently the name of the editbox object contained by the combobox and is of course totally hidden from any kind of examination. (sigh!)