Page #69 | Hackers Guide to Visual FoxPro 7.0

ActiveDoc

"Active" seems to have been Microsoft's word for the end of the 1990s. We have ActiveX, Active Controls, Active Desktops, and Active Documents. ActiveDoc is a base class (added in VFP 6, right in that end-of-the-'90s timeframe) that lets you run regular VFP apps in a browser. Frankly, we're not sure what's so "active" about these. In fact, "active doc" sounds to us like a physician who's always on the go, and doesn't make us think of browsers or applications or any of that.

Let's talk about the "how?" first and we'll address the "why?" (not to mention the "why not?") later on.

ActiveDoc is a shell into which you stuff your application. It handles all the interactions with the browser (called a "host" in the documentation, with the implication that there are lots of choices out there) and allows the application to run just as it always did. That's true to some extent, except, of course, that the interface you design for an app running under VFP probably isn't the same as what you'd design for a browser-based app. (We know, we said "why?" would come later, but it's hard not to say it now.)

The pieces all seem to work. The ActiveDoc gets things off and running and hands control over to a combination of the browser and the application. The browser talks to the active doc object, which in turn talks to the other portions of the app; there's even some chance for communication in the other direction.

Okay, we can't wait any more. What's wrong with this picture? The biggest issue is that the user has to have the VFP runtime available in order to run the app. That's right, you can't deploy an active doc application on the Web. You could use it on an intranet, but why bother? If every user needs the VFP runtime, why not just run a native VFP application? We haven't heard any satisfactory answers to that question, so we're not running out to turn all our apps into active doc apps.

But wait, there's more. While we were testing in VFP 6 and IE 4, ActiveDoc apps were about the least stable thing we encountered in VFP. We crashed VFP more testing active docs than any other portion of the product. Since ActiveDocs haven't taken off, we didn't think it was worth the time to test VFP 7 and IE 6.

So is there any point to ActiveDocs at all, or is it just one of those features Microsoft added to the product so that they could claim VFP builds Web apps? In the last version, we thought the venue of ActiveDocs was going to be quite limited. It's three years later and we've heard of no significant ActiveDoc apps. There are better options to do Web apps.

Despite all this, the design itself of the ActiveDoc object is fairly elegant. It has events that fire at appropriate times, including a couple that offer very sophisticated interaction with the browser.

Property	Value	Purpose
ContainerReleaseType	Numeric	Determines what happens when the browser releases the application.

Event	Purpose
CommandTargetExec	Fires when an action occurs in the browser that's not under the application's control, and gives the active doc a chance to modify or respond to the action.
CommandTargetQuery	Fires when there's a chance of browser action and lets the active doc decide what actions it wants to respond to.
ContainerRelease	Fires when something happens in the browser (like it gets shut down or the user navigates elsewhere) that means the application can't live there any more.
HideDoc	Fires when the user navigates away from the application.
Run	Fires when the application has been properly installed in the host (browser or VFP). This is the place to start things running.
ShowDoc	Fires when the user navigates to the active doc application and when the application first starts up.