>>>>>.. 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()
>

Possible, though when it's happened, it hasn't mattered what form we try to switch to. The form on top simply won't give up focus.

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

Have to think about how I could use that.

Tamar