PRB: Internet Explorer 4 Keeps Active Document Servers Running

Last reviewed: January 19, 1998
Article ID: Q177269
The information in this article applies to:
  • Internet Client SDK, versions 4.0, 4.01
  • Microsoft Visual Basic Professional and Enterprise Editions for Windows, version 5.0
  • Microsoft Visual C++, 32-bit Editions, versions 4.2, 5.0

SYMPTOMS

Active Document objects (also known as docobjs, .vbd files, and Active Documents) are not released upon navigating to a different URL using Internet Explorer. The server continues running even through several pages of navigation. This can cause problems for Active Document servers that expect the last reference to the Active Document object to be released upon navigating away from the URL that points to the structured storage file.

CAUSE

Internet Explorer 4.0 uses an unexpected way to keep Active Document servers in memory even after you have navigated away from the URL for the structured storage file (such as .vbd files). Immediately prior to releasing the reference to the displayed document, Internet Explorer will create another (hidden) instance of the Active Document object and hold the reference to that object for approximately 10 minutes, or when Internet Explorer exits, whichever comes first.

RESOLUTION

Here is some information for Visual Basic developers:

  • Do not use the Terminate event as a notification to shut down your Active Document server. The Terminate event will be fired once for each instance of the Active Document objects.
  • You will need to exit Internet Explorer while testing your Active Document server project, rather than simply navigating away from the URL for the .vbd file.
  • Avoid placing code in the UserDocument's Initialize or Terminate event handlers that should be placed in other event handlers (see MORE INFORMATION, below).

Here is some information for Visual C++ developers:
  • Do not expect the reference count for your docobj server to drop to 0 (zero) when the user navigates away from the structured storage file associated with your docobj server.
  • This behavior mimics the intended behavior of the method IClassFactory::LockServer(). You should continue to rely upon that method to keep your server running even if there are no references held against your objects.

STATUS

This behavior is by design.

NOTE: You should not make software design decisions that rely upon this behavior. Microsoft reserves the right to change this behavior without notice at any time.

MORE INFORMATION

There is no specification that requires an Active Document container, such as Internet Explorer 4.0, to maintain one and only one reference to an Active Document for each displayed instance. It can create as many instances as it likes.

Internet Explorer 4.0 uses this additional reference to keep the Active Document server running. Many Active Document servers, such as the Microsoft Office suite of applications, take a significant amount of time to get started. By using this additional reference to the Active Document object, Internet Explorer 4.0 can keep the server running, thus reducing the time it takes to display a page that has recently been viewed by the user.

Internet Explorer 3.x had a four-page "cache," which would hold references to the current page as well as the last three visited pages. Although Internet Explorer 4.0 does not have this four-page cache, the latent reference to the Active Document certainly acts like a cache.

For Visual Basic Developers

Many Visual Basic developers have a tendency to place application startup and shutdown code in the Initialize and Terminate event handlers, respectively, of their UserDocument objects. It is extremely likely that Initialize and Terminate events will overlap each other. In other words, you cannot rely on a single Terminate event to follow each Initialize event without other Initialize events in between. This makes the Initialize event handler a poor place to put code that expects to be fired only once during the lifetime of the Active Document server.

For instance, the following scenario can be expected to happen most times while using Internet Explorer 4.0 to view an Active Document:

   (... the user navigates to the URL of the VBD file ...)
   Sub Main executes (if applicable)
   UserDocument1_Initialize event fires (Instance #1)
   UserDocument1_InitProperties

    -or-

   UserDocument1_ReadProperties event fires (Instance #1)
   UserDocument1_Show event fires (Instance #1)
   (... other events ...)

   (... the user navigates to a different URL ...)
   UserDocument1_Hide event fires (Instance #1)
   UserDocument1_WriteProperties event fires (Instance #1; assumes the
      UserDocument.PropertyChanged method is called first)
   UserDocument1_Initialize event fires (Instance #2)
   UserDocument1_Terminate event fires (Instance #1)

   (... 10 minutes elapse, or the user exits IE4 ...)
   UserDocument1_Terminate event fires (Instance #2)
   (... the application terminates ...)

REFERENCES

  • Microsoft Windows Platform SDK: COM and ActiveX Object Services; Component Development
  • Visual Basic 5.0 Documentation: Component Tools Guide; Creating ActiveX Components
  • Visual C++ Programmer's Guide: Adding Program Functionality; Internet topics


Additional query words: DobObj
Keywords : AXSDKDocObjects AXSDKWebBrowser
Technology : kbinetdev kbole
Version : WINDOWS:4.0,4.01,5.0; WINNT:4.2,5.0
Platform : WINDOWS winnt
Issue type : kbprb


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: January 19, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.