Wondering whether anybody else is seeing an issue with Foxydialog in apps with WebBrowser control.

The affected app has _screen.visible=.f. and all forms are Desktop and top level or in top level.

FoxyDialog usually works well, with VFP forms becoming inactive as you'd expect with a dialog displayed.

However, if there's a WebBrowser it appears to stay active and actually can steal focus from the FoxyDialog that gets demoted behind the app forms. Then the app appears to freeze, as it awaits a response.

The affected WebBrowser control has a HTMLDocumentEvents class (as documented towards the end of this article https://www.west-wind.com/presentations/shellapi/shellapi.html ) so it's easy to confirm the issue with a code stub:

PROCEDURE HTMLDocumentEvents_onmousemove(pEvtObj AS VARIANT) AS VOID
wait window nowait "I am alive!"
ENDPROC


With foxydialog displayed, mousing over the WebControl confirms that it is indeed alive and can claim focus. You can alt-tab back to the FoxyDialog, but users will only see that the app is frozen. Or worse- the Foxydialog is no longer modal so the app can continue and you can end up with more than one concealed Foxydialog.

Not sure what to do about this. _VFP.Autoyield=.f. makes no difference and I am not sufficiently expert with API to check FoxyDialog source to enforce dialog modality. I am reluctant to hide or disable the WebBrowser as that would require a custom Foxydialog version for any app with a WebBrowser, which is not ideal. Any suggestions appreciated!

/edit/

Setting the Web Browser enabled=.f. doesn't solve the problem, but .visible=.f. does. I have wrapped the Foxydialog call in Try...catch to set a visible Web Browser invisible, then visible again.