>>>
>>>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
>
>Ed,
>
>On the one hand it sounds like you're telling me "Yes, of course you can do this", and on the other you say "You are not going to be able to accomplish what you want to do ...". Which is it, Ed? I didn't expect this to be the most efficient conceivable way of doing things, but then I don't know of any other way to have nested instances of full-blown VFP applications. Do you? Please don't tell me about the wonders of what I can do with the .NET framework, since it can't even run the simplest VFP application. Nor do I wish to become better acquainted with the splendid Win32 programming environment, to the extent that I can avoid it. I was just hoping to get a better understanding of the specific capabilities and limitations of this VFP/ActiveX-based approach.
>

Yes, VFP can spawn a process through the WebBrowser control and run an ActiveDoc in it, encapsulating the out-of-process instance of the ActiveDoc. Synchronizing the behavior of the contained ActiveDoc with the application is a different issue; the relationship between separate process instances vs multiple threads in a single process complicates exchanging data across the process interface. COM is a much simpler interface, and will probably have a lower cost in functional neurons in the long view - and other mechanism not involving VFP offer far stronger reliability and capability.

I know you don't want to hear it, but VFP is not the right tool for all jobs. ActiveDoc is a particularly lame capability that many people (including me) wish had never seen the light of day, because they give the impression that you can adjust a fine mechanical pocket watch using a 16lb sledgehammer. It may be doable, but it requires a much finer degree of control than, say, a jeweler's screwdriver. At least you're less likely for things to be totally FUBAR if you're off by a smidge in using the screwdriver...

If you don't want to know about the system issues, get the bullhockey about 'recursiuve execution of processes' out of the discussion, because they don't mean what you think they mean. There's more to recursion than simply spawning new instances; recursion implies that there is a directed graph of process dependency that can be constructed and must be maintained in order to resolve the recursion - IOW, you can't solve a node before its' child nodes have solutions. This guarentees that the recursive solution, while it is not known the exact magnitude of the cost of solution, it is computable, but not necessarily be finite. If you abort the execution of the child node prior to the completion of the child nodes, it's answer to its parent must be "I don't know."

>I don't think that direct inter-process communication and multi-threading issues have much bearing on my intended use of this form of recursion. Just as I can control a number of essentially asynchronous, independent browser windows, I would also like to control (i.e. host in child forms) independent instances of my application. My take on what you are saying is that you believe I can do this, but you don't see the sense of it.

Essentially; the real issue of asynchronicity is not the same as the concept of recursion because of the implied encapsulation of the recursion; while a recursive solution may be asynchronous, there comes a time in the satisfaction of the parent node computation that requires it to wait for the child to resolve itself and describe its result set to the parent. YMMV.

Technical words that sound sort of like the idea we have may not mean what they think they do...