>>It is horrid, but is the only solution without a coordination with container's member.
>>
>>

>>ELSE
>>  Container::setFocus
>>ENDIF
>>

>>
>>Fabio
>
>Interesting. I solved it similar way. I just put this.DatePicker.setfocus() after nodefault. It seems to work, though strange, I have to resort to this code. Sounds like a bug to me.

You can remove NODEFAULT, it is ignored.

Bug ?! A bad events design sure, a C++ program bug no.

Put this into the Container Lostfocus:

DEBUGOUT thisform.ActiveControl

this fire a error because never controls is active,
then VFP cannot stop the process.
Infact, when VFP execute Container::Setfocus,
is start a Form Setfocus sequence
( like when it found a NODEFAULT into a Gotfocus )

search firts When = .T.
Form.gotfocus
control.Gotfocus
...

Now, You can understand why I have used the word "horrid".

A good design require to stop the lostfocus process before
of the Activecontrol.LostFocus.

Now i use Throw for stop any process, but it generates many events trash.

A new design,

*Control.gotfocus
 BINDEVENT(m.this,"valid",m.this.parent,"valid",1)
*Control.lostfocus
 UNBIND....
*container.valid
 check....
 return .T./.F. ( into VFP9 : .NULL. / .T. / specificobject )

Fabio