>>>User clicks on a list. The item on which he clicked is highlighted. A message box appears. User responds to the message box. The message box disappears. The value of the list and the highlighted item are not in sync.
>>>
>>>If you think this is regular UI or if you're ok with events triggered by an user explicit action being "eaten away" after they occur, like they never happened, then good for you.
>>>
>>>It's not good for me.
>>
>>Perhaps you could track, in the debugger, the moment when the highlighted item in the listbox changes, and the value of its .listindex, .value and perhaps the .selected[.listindex] and if .displayvalue has any meaning in a listbox, that too. Watch them as they were before the messagebox(), then step by step afterwards. Perhaps you'll catch something. Though, as in all things focus-related, the debugger has the focus and the rest of the focus behavior is more or less simulated.
>>
>>A thing I'd try: after messagebox(), listbox.setfocus() (unless all of this is happening in a .valid(), then you can't do this).
>
>Dragan, thank you for your interest.
>
>I did track the event log, as I told before, and could not find trace of the click in the listbox that starts the text box to lose focus.
>
>Actual profiling from my application (no lines snipped in between but paths partially redacted):
>
>a) change focus from lstElementos to edtValor, all seems normal.
>

>   0.000251,,frmoperacao.lstelementos.interactivechange,15,---\geniua\forms\operacao.sct,1
>   0.000411,xeditbox,xeditbox.interactivechange,1,---\comum\basics\basics.vct,1
>

>
>b) the moment edtValor begins to lose focus (at this time, lstElementos was clicked on a different item that was properly highlighted, but there is no sign of any lstElementos events):
>

>   0.000077,xeditbox,xeditbox.interactivechange,3,---\comum\basics\basics.vct,1
>   0.001112,,frmoperacao.edtvalor.valid,1,---\geniua\forms\operacao.sct,1
>

>
>c) at line 12 of edtValor.Valid(), the Messagebox() is issued and removed by user interaction (3 seconds for that) but no more events are traced (the next event registers accessing the menu to turn profiling off - yes, I have a profiler on/off option in my menu to assist me in application development and test, go figure):
>

>   3.087909,,frmoperacao.edtvalor.valid,12,---\geniua\forms\operacao.sct,1
>   0.000358,sfbar,sfbar.click,5,---\xmenu\source\sfmenu.vct,2
>

Antonio,
(:ლ)

in danger to bore you.

There Click is not called at all
So if there is no event (click) shown (asuming you are tracing all, I miss mouse moves) - there is no event. So there is no code runing. As simple as that. Thats what I've told you. The click is gone because the messagebox deals wtih the eventloop and returns without. You see it and you still argue about it. The eventlog tells you the truth. No line for click visible - no click run.

I think your output is SET COVERAGE what is different. You should use SET EVENTLOG or turn it on using the debugger (the easy way) My eventlog on your form looks like:

81314,391, aform.thetext.MouseUp(1, 0, 123, 12)
81314,391, aform.thetext.Click()
81319,625, aform.thetext.KeyPress(97, 0)
81319,625, aform.thetext.InteractiveChange()
81321,719, aform.thetext.MouseLeave(0, 0, 121, 22)
81321,750, aform.chkx.MouseEnter(0, 0, 107, 50)
81321,797, aform.chkx.MouseLeave(0, 0, 99, 60)
81321,797, aform.thelist.MouseEnter(0, 0, 99, 60)
81321,797, aform.Paint()
81323,625, aform.Paint()
81323,625, aform.thetext.RangeLow()
81323,625, aform.thetext.RangeHigh()
81323,625, aform.thetext.Valid()
81323,641, screen.Paint()
81327,594, aform.thelist.When()
81327,594, aform.thetext.LostFocus()
81327,594, aform.thelist.GotFocus()
81327,594, aform.thelist.Message()
81327,594, aform.thelist.MouseDown(1, 0, 43, 86)
81327,594, aform.Paint()
81327,625, aform.thelist.MouseLeave(0, 0, 238, 215)
81330,172, aform.thelist.KeyPress(27, 0)

You see all the events you have no single line of code? That's Eventlog.

without your messagebox it looks like;

81962,391, aform.thetext.KeyPress(97, 0)
81962,391, aform.thetext.InteractiveChange()
81963,031, aform.thetext.KeyPress(127, 0)
81963,031, aform.thetext.InteractiveChange()
81964,063, aform.thetext.MouseLeave(0, 0, 137, 22)
81964,422, aform.thelist.MouseEnter(0, 0, 90, 90)
81964,719, aform.Paint()
81964,719, aform.thetext.RangeLow()
81964,719, aform.thetext.RangeHigh()
81964,719, aform.thetext.Valid()
81964,734, aform.thelist.When()
81964,734, aform.thetext.LostFocus()
81964,734, aform.thelist.GotFocus()
81964,734, aform.thelist.Message()
81964,734, aform.thelist.MouseDown(1, 0, 30, 71)
81964,734, aform.Paint()
81964,875, screen.Paint()
81964,875, aform.thelist.MouseUp(1, 0, 30, 71)
81965,844, aform.KeyPress(27, 0)

So the most important difference is, that in the first exasmple there is

81327,594, aform.thelist.MouseDown(1, 0, 43, 86)
81327,594, aform.Paint()
81327,625, aform.thelist.MouseLeave(0, 0, 238, 215)
81330,172, aform.thelist.KeyPress(27, 0)

While in the second it is

81964,734, aform.thelist.MouseDown(1, 0, 30, 71)
81964,734, aform.Paint()
81964,875, screen.Paint()
81964,875, aform.thelist.MouseUp(1, 0, 30, 71)

In the first case the listbox gets no mouseup. No Mouseup means - no click because the click runs after the MouseUp. This is because your messagebox gets focus and reads the mouseup event.
You even can see it. You press mousebutton down on the listbox - messagebox appears while you are holding the mouse down. The form has no focus (is not active, because the messagebox is) anymore and will not recieve any event.

As I have told you, your UI approach (Messagebox and then proceeding to next object) is wrong. If there is something to say about the textbox it needs to stop and stay within the textbox. The design of VFP asumes you will not complain about some input and then leave the object (because if you are gone there is no more control by the text box at all.)
Again:
Validation data on VALID event:
All fine -> ready to leave -> no messagebox
problem -> Messagebox possible -> stay in the textbox using RETURN .F. after messagebox.

You have my example. Try to eventlog the checkbox from the textbox as you do with the listbox. It will end up the same.

You might call it ugly, or a bug, but there is no change to it. Never ever.