Hi Rick,
I am experimenting with the Metro-Style Start Menu from your SWFox 2017 session. I have it working in my VFP9 SP2 Desktop App, very basic at this point.

I modified the first menu option to call one of the forms in my Desktop App. It calls the form just fine except, after the called form is displayed, it looses focus (becomes inactive) and the Start Menu Form becomes active again. It's like there is code in the IE ActiveX Control that is still executing that causes the Start Menu form to become active again.

Do you or anyone know what's causing this and a possible work-around? I tried a few things but nothing seems to help.

TIA,
Steve

I'm not sure what you're expecting. If the other secondary opened form goes away, focus will revert to the form (and control) that previously had focus. If you don't want that either hide the menu form (and re-activate it as needed from a top level menu) or at minimum set focus somewhere else before activating the new form.

The Web Browser control can have funky focus issues because it is essentially a top level window that the activeX control constrains to a form control. IOW, it's a full application level window and it can at times force focus and z-order to change when it gets reactivated which can force a form to the very top of the Z-order and keep it pinned there (like a AlwaysOnTop style form). There are ways around that by explicitly forcing the z-order or playing with AlwaysOnTop and Activate`Deactivate` on the host form.

+++ Rick ---

Thanks Rick. I played with the AlwaysOnTop and AlwaysOnBottom settings before posting the message. Even if I set AlwaysOnBottom = .T. just before calling my form, the Active Form is still the Start Menu Form. When I set AlwaysOnBottom = .T. on the Start Menu Form, the called form is displayed on top, but it is inactive (gray title bar) until I click on it. This is exactly in line with the behavior you describe. Thanks again for your insight.

Steve