>>>>All strange things used to happen in Friday. This is one of them. Imagine that you open list portion of combobox, browse by mouse over there and leave the area without selection (e.g. just click on some other control). It's not very nice (but understandable) to find out that Combo.Value is not corresponded to RowSource.Field anymore, but the worst case is that Listitemid or Listindex properties go nowhere after this action.
>>>>Can it kill some App logics? I just tested this for 3.0b.
>>>>Any comments?
>>>
>>>What about resetting the properties in Combo.LostFocus() ?
>>
>>Yes, following Combo.Lostfocus construction will help
>>cValue=this.value
>>this.value=""
>>this.value=cValue
>>But it's unbearable to code it for any combobox.
>>Nick, can you make me a favor and make quick test in 5.0a and post the results here.
>
>I tested this lostfocus under 5.0 (not "a"), and it works.
>Without this code I found that in 5.0 .Value actually doesn't change after clicking on another control, but listindex property usually becomes 0, but may be also match the last highligted row in combobox before clicking on another control.
>Probably this code may be added to the class.

Thanks, Nick! I see that Lostfocus code is really necessary in some cases, and should be always assumed. BTW, if Rowsource is a cursor, this 'mouse' closing of list portion invokes pointer moving to some record, i.e. if 'Lostfocus' code will not be added all relational construction goes to nowhere.
Best regards to MS Development Team.