Microsoft KB Archive/177269

= Internet Explorer 4.0 keeps Active Document servers running =

Article ID: 177269

Article Last Modified on 3/25/2005

-

APPLIES TO


 * Microsoft Internet Explorer 4.0 128-Bit Edition
 * Microsoft Internet Explorer 4.01 Service Pack 2
 * Microsoft Internet Explorer 5.0
 * Microsoft Internet Explorer (Programming) 6.0
 * Microsoft Visual Basic 5.0 Professional Edition
 * Microsoft Visual Basic 6.0 Professional Edition
 * Microsoft Visual Basic 5.0 Enterprise Edition
 * Microsoft Visual Basic 6.0 Enterprise Edition
 * Microsoft Visual C++ 4.2 Enterprise Edition
 * Microsoft Visual C++ 5.0 Enterprise Edition
 * Microsoft Visual C++ 6.0 Enterprise Edition
 * Microsoft Visual C++ 4.2 Professional Edition
 * Microsoft Visual C++ 5.0 Professional Edition
 * Microsoft Visual C++ 6.0 Professional Edition

-



This article was previously published under Q177269



SYMPTOMS
Active Document objects (also known as docobjs, .vbd files, and Active Documents) are not released upon navigating to a different URL by 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 Internet Explorer 4 ...) UserDocument1_Terminate event fires (Instance #2) (... the application terminates ...)

