>>>>.. Sometimes, when a user has two forms open, one of the forms won't give up focus.
>>>Nonetheless, I think I need to test this with Event Tracking on again to see exactly what's firing.
>>
>>Tamar, if event tracking doesn't help there is always "Binary Brute Force" ™
>>
>>Remove half the event code.
>>If it still fails, remove half again.
>>etc.
>>
>>Obviously, use a copy of the project, and save the halves as you go.
>>And easier by opening the form as a dbf, so you
>>can see all the Valid(), Losfocus(), When() and other suspicious and shady looking methods.
>>
>>The few times I had issues that could not be found using the debugger, this did work.
>>It took a lot less time than I feared.
>
>Nontrivial in this case. There's a lot of code at a lot of different levels from the base classes through intermediate classes to the form itself. I think I'm more likely to use a liberal sprinkling of DEBUGOUT commands than to start removing code.

Understood about nontrivial - it is a very rough way to treat your project.
Really only useful on a throw-away copy of the whole project.

The base classes can probably be left alone - just put NODEFAULT in the form events to disable the event.
My money is on a rogue When() or Valid()

Maybe it is not the form you are leaving, but the form you are trying to jump to?
I had something similar while attempting to set focus to a control that returned .F. in it's When()

Have you tried using an ON KEY LABEL to set focus to some test object?