Barry,
"more like just looking into another room to get some information to enable it to lose focus!"
Answer is in this sentence. Despite valid, lostfocus is the ideal place IMHO. By default in lostfocus you lost the focus and have right to setfocus anywhere even to the object that lost focus. There is a corrected behaviour (bug) that existed in all versions from foxpro 1.x up to VFP7. You could leave a control in a grid (foxpro browse) when valid returning .f. by clicking a control outside the grid. Now you can't. I think this is related with it and should be that way. It's more 'how you should do it' rather than a workaround to use lostfocus :

* What ever action like invoking other forms, controls, messages
* even you could move pointer to other recs 
* if row validation permits and applicable
llValidated = WhateverCheckforValid
if !llValidated  && Invalid input - stay there
 nodefault       
 this.setfocus
endif

If you have time check FoxyClasses EditGrid sample. There 'reportsto' accept '?' as an indicator to get supervisor name from a LocatorGrid shown with a modal form.
Cetin

>Hi Cetin,
>Thanks for the information. I always found in VFP6 an error was generated when you tried to set focus from within the valid of another object - for the very reason you stated.
>
>Both Don and I have been trying to call up a modal form which allows the user to enter (or select) a value which is returned to the valid method of the calling object ( a text box in a grid). In my case, I require to do some supplementary checking of the value returned from the modal form and so I need to stay inside the valid method of the text box. In my opinion, this should be an acceptable use of the valid method. I would not regard this as the calling object losing focus - more like just looking into another room to get some information to enable it to lose focus! If I leave the modal form call (to get the user's value) until the lostfocus event of the textbox it is too late.
>
>I have tried keeping the modal call in the valid method and putting an explicit setfocus() call in the lostfocus of the text box to reset the focus to the next grid column. This does improve matters as the grid regains focus but it means that user movement around the grid is now restricted and some strange results now occur which are difficult to describe consistently.
>
>
>Regards
>Barry
>
>
>>Hi Barry,
>>I don't think it's a bug but a correction to behaviour. FWIW calling another visual object from a valid event is dangerous. Since caller hasn't validated yet it shouldn't lose focus but it does in VFP6 ! Formerly being able to call setfocus from a valid was a corrected bug.
>>Just moving the code to lostfocus cures it and as far as I remember it was the case with Don's form too.
>>Cetin
>>
>>>Hi Don,
>>>
>>>I have encountered the exact same bug where you have a modal form returning a value into a grid text box - fine in VFP6, but locks up in a most peculiar way (not entirely frozen) in VFP7. Did you ever get to the bottom of this?
>>>
>>>An app with the above grid functinality now seems to work as follows:
>>>Running a VFP6 version of the app in a VFP6 environment works fine. (obviously)
>>>Running a VFP7 version of the app in a VFP7 environment breaks.
>>>Running a VFP6 version of the app in a VFP7 environment breaks.
>>>Running a VFP7 version of the app in a VFP6 environment works fine. (But obviously would not if we were to use any of the VFP7 language enhancements).
>>>
>>>ie the workings of the VFP7 development environment do not seem to have changed with respect to grids, but the runtime VFP7 is handling grids differently.
>>>
>>>I am way out of my depth on this, being but a simple one-man band trying to keep a small office application together. I have been pretty unhappy with a few peculiar behaviours that seem to have crept in following the upgrade. :-(
>>>
>>>For the time being I am going to revert to VFP6 - and hopefully the gurus out there will take heed!
>>>
>>>Regards
>>>Barry Sutton
>>>
>>>
>>>>Hi Mark,
>>>>
>>>>Thanks for the response.
>>>>
>>>>The Modal form is called from the textboxes valid event just like you suggested (if the user enters a '?) and the lookup form returns
>>>>the passed variable via the unload event. I'm just wondering you can duplicate my problem and if not then it's something I'm doing
>>>>.... but it worked just fine in version 6.0. All I'm after is a simple lookup that upon selection returns the value the grid during data
>>>>entry.
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>Don