>What is the VALUE of your combo box during each of these procedures.

I did the same experiment as previously described, but I also tracked the combolist value, oldval("mytablefield"), curval("mytablefield"). Same result. When I use the downarrow key to modify the work order number being selected, ALL of the state variables change to new values as expected. None of these state variables contains any value that would appear to allow VFP to revert back to the original value (and therefore, original record) selected. I can only presume that some hidden state variable is the culprit.

Is the controlsource set to a field in another table?

No. For your information, the pertinent combolist properties are as follows:

boundto = false
controlsource = none
rowsource = wojrn.wono (WorkOrderJournal.WorkOrderNumber)
rowsourcetype = fields
style = dropdownlist

As you can see, I'm using the combo as a drop downlist, so I'm not modifying the value of the work order number in the table. I merely use it as my look up index.

It sounds like the combo value isn't getting updated, so when you click on it the value resets to the original value.

I agree that some internal mechanism is not getting updated. However, all of the state variables I am allowed to see do appear to be getting updated. One of the key clues must be related to the fact that if I break execution in the combo's gotfocus and then continue execution, the problem does not occur. This behavior makes some kind of race-condition suspect --- my table is located on a network server.

Origninal message follows:

>>I have a combolist that specifies a work order number in my work order journal. If I set its value with the drop down list, then alter its value with the downarrow, then click on another control, the return by clicking on the combolist, the combolist reverts to the value selected prior to using downarrow key. In more detail:
>>
>>1. Using mouse, Drop down the combolist and select a work order number with the mouse. Result: new record is selected. RECNO(),LISTITEMID & LISTINDEX all correspond to the selected workorder number as expected.
>>
>>2. Use downarrow to go to next work order. Result: new record is selected. RECNO(),LISTITEMID & LISTINDEX all correspond to the selected workorder number as expected. (IOW, all combolist state information available to me indicates that a new record has been selected!)
>>
>>3. Use mouse to move focus to another field (textbox) of the record.
>> Nothing changes. As expected.
>>
>>4. Click on combolist (either in its textbox or dropdown button, it matters not). RESULT??? Value of work order returns to the one I selected in step 1. Value of recno(),listitemid & listindex correspond to original workorder number selected. How did VFP know how to go back? Where is this old state information stored? Why does it go back?
>>
>>If I trap anywhere in the combolist.gotfocus then continue, the problem does not happen. I even put a dodefault() in the gotfocus and trapped before and after. (For some reason, the gotfocus is calling the combolist.message() method but I'll be damned if I know why!). Halting the process anywhere in gotfocus prevents the problem.
>>
>>If I do not trap, some internal VFP mechanism resets to the original record and then fires interactivechange. Trapping on entry of latter reveals that the reversion back to the old record has already occurred.
>>
>>Trapping on the access of any of the pertinent state variables of the combolist is ineffectual. I presume that this is because the error occurs inside hidden VFP code where trapping is not allowed.