Hi again David.
I thought I'd let you and others know that I now have a generic solution. My toolbar buttons and menu objects will all by default call a "focusshift()" method in the form which must return .t. or the action doesn't occur. This method uses a special "off-form", "no tabstop" button which it attempts to setfocus() to. If that button then has the focus then all is well and I proceed to the action. This has the advantage that it traps ALL VFP and coded events associated with moving the focus including the native date validation. So clicking on the toolbar or choosing a menu item can be identical to clicking another button on the form. Works great for me.
And it removes focus from the grid, so no alias problems.
And it automatically updates the controlsource before the valid() fires.
Focus is restored automatically when the action is complete.

Wooo hoooo! I'm a happy chappy.

This effectively replaces my old "form.writebuffer" which many people have in one form or another in their form base class.

I have code if anyone is interested.

>David,
>
>What are the datasessions of your forms?
>
>I just did some tests and by form.LostFocus() or form.Deactivate() time thisform.ActiveControl has already been invalidated.
>
>So I thought about approaching it another way of checking what the current alias() was on the way out of the form, but at deactivate time VFP has already set the current workarea to the same workarea that was selected at the end of the form.Load(). For example in form.Load I created two cursors X1 and X2. X1 had one row and it's columns were bound to textboxes. X2 had several rows and was bound to a grid. I made sure that X1 was the current alias at the end of the method. Then in deactivate I tested the current alias, but it was always x1 even if the grid was the control with focus at the time I clicked to another window.
>
>If x2 was the selected alias at the end of Load, that was the workarea that remained selected regardless of where I tried to setfocus.
>
>

* form.Deactivate()
>if ( alias() = "X2" )
>*   thisform.text1.SetFocus() && - doesn't change to x1
>*   debugout "change to text1"
>   select x1 && this will alter workareas
>endif

>
>the above code will in fact make sure that the grid workarea is not selected as the form loses focus.
>
>So that brings me to the question about what sort of data sessions your forms in question are using.
>
>>The other form could really be anything, menu options, buttons, events whatever. So I don't believe there's any generic way other than the firing of lostfocus or deactivate. Can't even guarantee lostfocus because a form with empty (unpopulated record source) grid doesn't get focus.
>>So it leaves "deactivate" - but that's too late.
>>I guess i'm kinda stuck for a generic solution. I can certainly change focus away from a grid or other data bound control if an option is selected which I "know" is going to cause alias problems. I can even store that object reference in a form property so that when it activates I can reset to the original.
>>I was kinda hoping that since VFP clearly knows and remembers the active control (even though form.activecontrol returns nothing) that there would be another way to access it. I summary, what I'd really like to do is change the activecontrol on a form that isn't active or is about to become inactive. But I guess that would create ALL sorts of issues with events firing. Oh well :-(