>
>I understand that ActiveDoc is just a way of packaging a local VFP application, not a way of running it across the web. But must I be limited to using a VFP ActiveDoc-based app through the interface of Internet Explorer, or can I have the choice of using the WebBrowser ActiveX control? I'm not aware of any restriction that prevents the use of the WebBrowser ActiveX control from opening anything that can be opened via IE. After all, this control is used internally by IE, and it does most of the work, so I would normally have assumed that the answer is Yes, you can open a VFP ActiveDoc-based app via the WebBrowser ActiveX control.
>

The WebBrowser ActiveX is nothing more than a container for an instance of InternetExplorer.Application; IOW, it's another freaking instance of IE. Yes, it's an instance of IE, so it can host an ActiveDoc - lessee, load a copy of the VFP RunTime and an instance of IE manipulated through the VFP UI so I can load another instance of the VFP RunTime and use the contained interface to host the runtime app with file I/O redirected...seems like a brilliant way to run down resources and kill app performance from here! Should sell a lot of RAM and new processors for you...not to mention more bandwidth so the redirected I/O will be acceptable. < BEG >

>However, the omission of any mention of this mode of using VFP ActiveDocs makes me suspect that there may be some special restriction on the WebBrowser ActiveX control for the particular case of VFP ActiveDocs. Why does the documentation fail to mention this, when it seems to me like a far more interesting usage than that of launching a VFP app within an instance of Internet Explorer? I agree with you that one might as well simply launch the VFP app directly in that case.
>
>Perhaps I am misunderstanding the concept of Active Documents, but I'll explain exactly what I have in mind. If I can launch a VFP app within a WebBrowser ActiveX control, it means (I think) that I can build a kind of recursive VFP application, which cannot be constructed in any other way. For example, it means that my application can contain a child form which contains another instance of the application itself, and that child application could contain further nested instances of the same application. This is a very general recursion issue, which has nothing to do with web connectivity. My only reason for bringing the WebBrowser control into the picture is that it is the only type of container that can (I hope) host an ActiveDoc-based VFP app. Do you see what I'm getting at?
>

You don't understand the containership issues for launched processes in the Win32 environment. I'd suggest reading either Charles Petzold's book on the Win32 Programming environment, or Jeff Richter's Advanced Windows to understand the asynchronicity of independent processes in the Win32 application environment and IPC. You are not going to be able to accomplish what you want to do with this since the ActiveDoc is outside the process space of the hosting application and there is very limited coordination and signalling available through the IE interface. You'd be far better off investing in out-of-process servers and an IPC mechanism that worked interprocess on a single machine, or in .Net and ignoring VFP entirely if this general process recursion is a real requirement of the app - you need multithreading and a different thread model to do what you seem to be describing, and DCOM/local out-of-process COM is far more complex than working with the .Net framework, with a hellof a lot less work and infinitely tinier footprint than multiple instances of IE and the VFP runtime forced into a containership hierarchy...

>Mike