>There are some known issues with ActiveDocs, and their usage is not advocated. In fact, I would recommend that you avoid using ActiveDocs in VFP, they may not even be supported in future versions of VFP. We work very hard for full backward compatibilty, but ActiveDocs may be a special case since they do not offer much security and there are very little business cases for their use. What I would recommend is to use ASP.NET with VFP as a replacement for any application that does or may consider using ActiveDocs.

Ken,

Thank you very much for replying. I gather that VFP Active Documents have very little support, in every sense. No one seems to consider them useful for anything practical, especially when it comes to Internet applications.

I have no argument with this, except perhaps for one class of applications, of which mine is an example. There is no security issue here, and ASP.NET offers nothing as a replacement for achieving what I'm trying to do, which is to create physically nested instances of a full VFP application, running locally. Active Docs offer a relatively easy way to accomplish something that is otherwise difficult if not impossible to achieve.

While there are clearly some serious "issues" with ActiveDocs, if we confine our attention to those bearing on the sort of purely local usage I'm describing, the problems may be readily solvable, and well worth solving. As I see it the benefits of Active Documents, properly used, are that they provide easy ways to:

A. encapsulate an entire VFP app in an imbedded window controlled by another app
(or in my case another instance of the same application)

B. obtain the benefits of multi-processing

My tests indicate that VFP ActiveDocs essentially work, and their performance is not a problem. The problems I've encountered are not minor, but there is reason to think they can be solved without too much difficulty. Specifically, I've identified these problems:

1. limited inter-process communications

Of course it would be really nice if there existed a built-in mechanism for direct communication between the ActiveDoc container and the contained ActiveDoc. But in the absence of that, any general Windows inter-process communication facility that can be accessed from VFP will do. Since VFP processes can easily share data, even the crudest, slimmest additional channel of direct communication will suffice. I don't know much about this area of Windows APIs or whatever, so I'm hoping someone will help point me in the right direction.

2. apparent bug relating to the need for implicit activation

As described in my earlier message on this thread, there is a problem with the flaky behavior when the focus is moved from one process to another. There may be a simple workaround, or perhaps this bug could be easily fixed. I'm looking for help on this specific problem.

3. delay on closing

Arguably this is another bug, but if it's by design I would say it's a flawed design that could be easily fixed. Some research I did suggested that it may have something to do with pinging 3 times before the container decides to kill the ActiveDoc. (Again a symptom of the very limited communications channel.) If I used my own channel of communication, I could easily avoid this delay with a small piece of code in the parent's Destroy event method.

4. absence of main menu in the ActiveDoc

This appears to be a bug, possibly inspired by the misguided focus on hosting VFP ActiveDocs in Internet Explorer, as opposed to hosting in the WebBrowser ActiveX control. I'll bet this wouldn't be a difficult bug to fix. I can live without it (not that I'm encouraging you to neglect fixing this), because I can supply other kinds of menus and toolbars as a semi-satisfactory substitute.

Despite these problems, I still see ActiveDocs as something that could be much more useful than is widely recognized. Consider the history of private data sessions. Yes, we could have managed without them, but they really were a boon to the power and ease of using VFP. ActiveDocs can be seen as an analogous extension, providing an even greater degree of total encapsulation and isolation of an application within another application. This really is a very general programming issue, not just one pertaining to my unconventional application.

I don't know if I've done anything to save this feature from extinction, but I do feel obliged to make the case, and I hope you will ponder this further before deciding to give it the ax. Can I expect ActiveDocs to still be supported in Toledo? Can anyone offer some help with the specific problems I've mentioned?

If Microsoft has come to a definite decision to discontinue support for ActiveDocs, it would be a big disappointment, but it would be best to share that information sooner, rather than later. You certainly seem to be leaning that way, and I respect that this is Microsoft's business decision. In the meantime, it would be very helpful to have as much assistance as possible and information about your plans for continued support of ActiveDocs.

Mike