Thank you so much for your reply, Lutz.

>
>Not realy related but skip the use of those wait window. Start debugger and use DEBUGOUT. This will not move focus. Also if you miss to remove, it will not harm in runtime. Even if you use a hand axe like VFP, there is no need to stuck to outdatded debugging tools.

This is a demonstrator program, it is not production code not even development code. WAIT WINDOW NOWAIT is not slurping the focus away from any control in the form and its use provides a self contained environment to verify the problem replica. But feel free to use the debugger, as I already did, in case you're interested to dig into this.

>
>In general, a Messagebox will play araound with active windows. So If you call a Messagebox, your form will be deactivated , messagebox will shown and form will be activated after. What means gotfocus events and whatever might fire too. Check EVENTLOGGING (but this is a pain)

Already checked event logs. I can see no trace of the lost click on the list item, the one that starts the textbox to lose focus. And yes, the form is deactivated, as it should. But the problem remains: there is an highlighted item in the list that does not correspond to its value.

>
>Try to run your code without the messagebox, just with a ? or a debugout for testing, if this runs, your problem is related to focus problems as mentioned above.

Yes, I know that. But that does not solve the problem.

>In general validating while input is a pain. I validate on records tableupdate level, much less fuss. (To me)

This is a value format validation. It's like having a text control to expect for a number, or a text, or a date. Don't you use constraints in your input objects? This follows the same principle.