>>Antonio,
>>(:ლ)
>>
>>in danger to bore you.
>
>No, not at all!
>
>>
>>There Click is not called at all
>
>Yes, I was going to correct myself, but you stepped in and rightly so. The click is trappable but there is not much we can do with it (because the control visual and data states are out of sync).
>
>>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.
>>
>
>[snip]
>
>>
>>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.)
>
>With this I strongly disagree, and there is nothing in the VFP design that designates that kind of behavior you're assuming. In fact, the design of valid() is such that we were given the chance to move focus specifically to any control in the form from there. And, of course, the purpose of a Messagebox() is not only to "complain".
>
>>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.
>
>Yes, I know that if I stay in the text box there will no problem. In this case, it's up to the user to decide, in face of the information the application gives him back. But if he decides to continue and got out of the box with a click on the list, his action won't be honored.
>
>I wouldn't mind if the highlighted item remained the same. What cannot be is to give the user a visual information that does not correspond to the actual state of the control.
>
>That is ugly and a bug.


#1 Messageboxes are to complain. Messageboxes act in a way that interupt normal behaviour of the program (try to close any program with messagebox open, for example) that there use should be very limited. There are not designed to give each and any information.
#2 As I've told you. If it is a bug or not changes nothing. Try to ask M$ to fix it.
#3 A workaround I can think of (to do something constructive)

CLEAR ALL
PUBLIC loForm AS aForm

CLEAR
loForm = CREATEOBJECT("aForm")

m.loForm.SHOW(0)

DEFINE CLASS aForm AS FORM
 ALLOWOUTPUT = .F.
 AUTOCENTER =.T.
 WINDOWTYPE = 0
 goRestObj  = .NULL.
 ADD OBJECT theList AS aList
 ADD OBJECT theText AS aTextBox WITH LEFT = 100

 ADD OBJECT chkX AS CHECKBOX
 chkX.LEFT = 100
 chkX.TOP = 50
 chkX.CAPTION = 'No Messagbox'
 chkX.VALUE = .F.

 ADD OBJECT tmr1 AS TIMER
 tmr1.ENABLED = .F.
 tmr1.INTERVAL = 10

 PROCEDURE tmr1.TIMER
  THIS.ENABLED = .F.
  IF VARTYPE(THISFORM.goRestObj)='O' AND !ISNULL(THISFORM.goRestObj) THEN
   THISFORM.REFRESH
   THISFORM.goRestObj = .NULL.
   THISFORM.LOCKSCREEN = .F.
  ENDIF &&VARTYPE(thisform.goRestObj)='O' AND !ISNULL(thisform.goRestObj)
 ENDPROC &&tmr1.timer
ENDDEFINE &&aForm AS FORM

DEFINE CLASS aList AS LISTBOX

 PROCEDURE INIT
  THIS.ADDPROPERTY('glTestClicked',.T.)

  THIS.ADDITEM("Item 1")
  THIS.ADDITEM("Item 2")
  THIS.ADDITEM("Item 3")
  THIS.LISTINDEX = 1

 ENDPROC &&INIT

 PROCEDURE INTERACTIVECHANGE
  ?"InteractiveChange(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
  THIS.glTestClicked = .T.
 ENDPROC &&INTERACTIVECHANGE

 PROCEDURE PROGRAMMATICCHANGE
  ?"ProgrammaticChange(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
 ENDPROC &&PROGRAMMATICCHANGE

 PROCEDURE CLICK
  THIS.SETFOCUS
  ?"Click(): " + TRANSFORM(THIS.LISTINDEX) + "/" + THIS.VALUE &&NOWAIT NOCLEAR
  DEBUGOUT 'clickevent'
 ENDPROC &&CLICK

 PROCEDURE GOTFOCUS
  ?'got'
  IF !THIS.glTestClicked THEN
   ?'set',THIS.LISTINDEX
   THISFORM.LOCKSCREEN = .F.
   THISFORM.goRestObj = THIS
   THISFORM.tmr1.ENABLED = .T.
  ENDIF &&!THIS.glTestClicked
  THIS.glTestClicked = .F.
 ENDPROC &&GOTFOCUS
ENDDEFINE &&aList AS LISTBOX

DEFINE CLASS aTextBox AS TEXTBOX
 PROCEDURE VALID
  ?'valid'
  IF !EMPTY(THIS.VALUE) THEN
   IF THISFORM.chkX.VALUE THEN
    ??' just print'
    ?"Some validation..."
   ELSE  &&thisform.chkx.value
    ??' Messagebox'
    MESSAGEBOX("Some validation...")
   ENDIF &&thisform.chkx.value
  ENDIF &&!EMPTY(THIS.VALUE)
 ENDPROC &&VALID
ENDDEFINE  &&aTextBox AS TEXTBOX

see additional timer tmr1 in the form, additional property goRestObj, addtionale code in Interactivechange and additional event GotFocus

It's a kludge and a bit generic. If you use it you owe me a postcard. I realy hate such work.

Update:
goRestObj.VISIBLE replaced with goRestObj.REFREH. Change of LISTINDEX in GotFocus removed. Works as well.

The LOCKSCREEN might be removed, but then the listbox will flicker.