>Michael
>
>FWIW, we spend *heaps* of $$ investigating ActiveDocs and gave it away. It is just a fat client vfp app in a browser. You still need the VFP runtime dlls at the client, you still need to register any activeX you use. So why do it? Sure there is political/marketing capital in "web apps" at present but you can mimic that with a smart installer.
>
>Is there another reason why the app has to be ActiveDoc?
>
>HTH
>
>Regards
>
>JR

John,

I have tried to make it clear that there are at least two entirely different ways of using VFP ActiveDocs. The type of usage we agree is not useful, which is the only scenario that Microsoft's documentation has ever described and the only scenario heretofore discussed (as far as I know) is that of hosting a VFP ActiveDoc in an instance of Internet Explorer. I am in total agreement with you and the vast majority of others who have voiced an opinion on this.

Now consider an altogether different way of using VFP ActiveDocs, which I first brought up in thread 627455. Instead of hosting an ActiveDoc in a free-standing instance of Internet Explorer, I'm talking about hosting it in a WebBrowser ActiveX control, residing in a form within a parent VFP application. The net result is that the outer VFP application physically contains and controls a window (i.e. a form) that contains another instance of an entire VFP application running in its own separate process. This is something that is both useful and not achievable by any other means, and the idea can be carried to further greater degrees of nesting as well.

Don't be misled by any apparent similarity between these very different ways of using VFP Active Docs. The purpose of my proposed usage has nothing to do with "web apps". I'm not trying to pass anything, data or programs, across the Internet, and there is no assumption of an Internet connection in the scenario I describe. Everything resides on a local client machine, and since the main application is VFP, there are no "extra" installation steps or security issues related to this way of using VFP Active Documents.

The application I'm developing, called Montage, clearly illustrates the usefulness of hosting VFP ActiveDocs in a WebBrowser control. Montage is a multi-windowed viewer/explorer that saves and restores its state (i.e. the configuration of many constituent viewers) in a special type of metafile, which I call a montage. Montage has viewers for a variety of file types, based on various flavors of native VFP controls and ActiveX controls, and it uses these to open windows (i.e. forms) within an outer window (the VFP main screen). Besides viewing the usual types of files (text, image, HTML, etc.), Montage supports a nested montage viewer, i.e. a way of opening a montage within a montage. The most straightforward way of implementing this is through a VFP ActiveDoc, hosted in a WebBrowser ActiveX control.

While it may be possible to accomplish something similar by using ACTIVATE WINDOW ... IN ..., the intermixing of VFP's object-oriented forms and older VFP WINDOW commands is awkward, and it greatly complicates the programming of such an application. Also there are numerous global VFP resources that add further complications, making it difficult to cleanly separate the basic problem from its recursive aspects. With ActiveDocs, there is a clean separation, because each instance of Montage has its own _screen, its own current directory, its own entire VFP environment. As I said before, this is analogous to the idea of private data sessions, but providing an even greater degree of isolation between separate, but loosely interrelated applications. An added benefit of the ActiveDoc approach is that it introduces an easy way to harness the power of multiple processors.

After all that Microsoft has invested in supporting Active Documents, it would be a shame to lose this feature so shortly after the discovery of a significant, legitimate use for them. I hope that you and others will give some serious thought to what I'm saying, rather than dismiss this subject so hastily. Please think about it, John.

Mike