>>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,
BINDEVENT(m.this,"valid",m.this.parent,"valid",1)
UNBIND....
check....
return .T./.F. ( into VFP9 : .NULL. / .T. / specificobject )
Fabio