Hu Inline reply. :)

>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.

It's general advice. Wait Window is so CP/M

>>
>>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.

So, you say that if you pint instead of messagebox the error remains. Then it is not bound to the messagebox. Something else is the problem.
You might run through your code and trace / breakpoint the value. Note, this is tricky. You can set THIS.listbox.value to the watch window end set a breakpoint to it. But this will go out of focus. so you need to bound this to a public variable ant watch for publicvar.listbox.value. You might find the place that alters your value this way.

>>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.

Nope. I let the user enter and check after they try to save. User (I'm in a small corner) found it ugly to have those checks on every boring text box. I was happy about it.
A textbox that excepts a number is a number, one that excpects date is of date type. Why should I deal with chars? It would only be meaningfull for ranges or uniqness - but unique could be over more then one field so this is on save too.
All what I say - it's my style and I'm happy to have not this frustrating stuff in each and every input object. I have depencies for enable etc. - but they run over central methods on eventbinding.
Also VFP is by design a pain with VALUE, a lot of times INTERACTIVECHANGE needs a THIS.SETFOCUS to have THIS.VALUE or more controlsource set to the value entered.

Have nice weekend.