Pardon me for jumping in
If you have a modal form on the screen, you should not set focus to any object outside the active modal form. Setting focus to another form with a timer or otherwise when the active form is modal causes the (previously) active modal form to become inaccessible thereby locking up your application. I suspect doing so really screws up the zorder of the forms collection and once the modal form loses focus in this way, there is no way for it to regain focus.

One thing you could do in the timer event or whatever is setting focus outside the modal form, before setting focus to another object, check to see if the active form is modal.

*!* in timer event on Non-modal form   
if _VFP.activeform.windowtype <> 1 or _VFP.activeform = thisform
    thisform.Command1.setfocus()  
endif 

Whether it is a bug in Visual FoxPro or not, I can't say, but you "can" (but should not) inadvertantly setfocus to any object on another form when the active form is modal as it WILL lock up your application. I think the key is to sparingly and properly use modal forms and never set focus to any control not on the active modal form. The above may be considered a workaround to prevent the "bug" behaviour when the active form is modal.

HTH

>> ...>> You are semi-stuck now, right?>> You are in the same condition that the timer would put you in.>>Yes. So? I agree that the bug can be "fired" by many ways. Do you have a way to fix the bug?>>> My point is that I think you would have problems like this in *any*>> language, because of the way that modal forms work.>


>> Well, before we find the reason, I wouldn't speculate. :)
>
>Well said, Michael.
>
>I do not know how to fix it. Actually, my message to the forum - it's a my "Last try". The problem was found about half year ago. I spend a day and did not find a solution. I have fixed it by very stupid way : I have put a "ThisForm.SetFocus" instruction into Deactivate method of every modal window that can be called from the Process screen. It worked well until we have translated our product to another languages. We have used INTL toolkit. Here the problem : INTL use modal forms instead standard MessageBoxes. So, it does not work together with my dirty patches.
>
>I'm out of ideas.
>
>
>>Well, maybe you could have the robot process to run in one app and the user
>>input on the other app, both 50% of the screen. :) Or, issue some kind of
>>automation COM object being launched from the main app, where you would
>>preserve the control from the main app, and maybe it would react better.
>
>The life is more complicated. The application takes one display in two-display system. Second display is used by another application (WonderWare). And I use "some kind of automation COM object" :-) to make them work together.
>
>And second reason: the product leave already about 8 years (it was started, I belive, in FoxPro 2.x). It's absolutely impossible to rewrite whole code to avoid a VFP b... feature.