>ActiveDocs are nothing more than a VFP rich client desktop window running inside the IE browser, and you can run a form or VFP app outside of the IE browser just the same. The only real functionality of an ActiveDoc is that it hosts a VFP form within an IE window, and you still need the VFP runtime on the desktop to run it so it is not a thin client and it can't be compared to thin clients. Also, there are many security issues using ActiveDocs.

Ken,

I don't wish to be argumentative, but your assertion is incorrect, and you have not responded to a single one of the technical points that I made. Hosting an ActiveDoc in a WebBrowser control is not the same as hosting it in an IE window, and as I pointed out it has absolutely nothing to do with building web-based applications. The fact that the WebBrowser control is involved is merely an artifact of the limitation that this is the only control that can host a VFP ActiveDoc. There are no security issues in building an app that runs locally and happens to employ ActiveDocs as a device for composing a modular, layered, multi-processable application. This is not about building "thin client" apps, and it is assumed that the client must have the VFP runtime installed anyway.

Please don't mix up the very different scenarios that have been discussed as to how ActiveDocs can be useful. I believe that the kind of usage I've described, in a WebBrowser control, is far more justified than you are giving it credit for. That others have failed to take note of this can be largely attributed to fact that Microsoft's documentation has never made this clear. On the contrary, the only usage of VFP ActiveDocs that has been documented is one which, by your own admission is relatively useless and unjustified in almost all cases.

Mike