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.