Vidar,

The normal sequence on tabbing out of a field is for Valid() to fire and then LostFocus(). Valid basically determines if it's ok to leave the control, if it returns .T. then the LostFocus() event will occur to let you know that the control is indeed losing focus. Part of the baseClass behavior of LostFocus is to start the process of moving to the next control.

1) I'd avoid calling Valid from LostFocus. Instead I think I'd use Valid to set a control property that could be tested in LostFocus. Although this might not even be necessary because I think LostFocus firing implies Valid()=.t. But if it's some other condition that determines if the child form should be launched and not the Valid state of the control then you'd have to set a flag:

<b>Valid:</b>

if ( SomeCondition )
   this.DoChildForm = .t.
endif

<b>LostFocus:</b>
if ( this.DoChildForm )
   nodefault && prevent automatic execution at end of override code
   TextBox::LostFocus() && explicit call to it
   DoDefault() && do inherited class hierarchy code
   do form TheChildForm
endif

<b>GotFocus</b>
this.DoChildForm = .f.

If the SomeCondition test can be fully tested inside the LostFocus() you could do away with the flag.

One thing you can do to help track this kind of thing down is to use EventTracking in the debugger.

>Well it's not really a call from a button, but from a continer object with a text field. The user inputs a value and hits TAB to leave the field. Then the containers' lostfocus method calls a valid method which launches this other form. The lostfocus then continues after the valid and the focus is set to the next field on the form. This is probably why the focus shifts back to the first form. How should I attack this problem?