Internet Explorer 4.0 keeps Active Document servers running (177269)
The information in this article applies to:
- Microsoft Internet Explorer (Programming) 4.0
- Microsoft Internet Explorer (Programming) 4.01
- Microsoft Internet Explorer (Programming) 5
- Microsoft Internet Explorer (Programming) 6.0
- Microsoft Visual Basic Professional Edition for Windows 5.0
- Microsoft Visual Basic Professional Edition for Windows 6.0
- Microsoft Visual Basic Enterprise Edition for Windows 5.0
- Microsoft Visual Basic Enterprise Edition for Windows 6.0
- Microsoft Visual C++, 32-bit Enterprise Edition 4.2
- Microsoft Visual C++, 32-bit Enterprise Edition 5.0
- Microsoft Visual C++, 32-bit Enterprise Edition 6.0
- Microsoft Visual C++, 32-bit Professional Edition 4.2
- Microsoft Visual C++, 32-bit Professional Edition 5.0
- Microsoft Visual C++, 32-bit Professional Edition 6.0
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
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 ...)
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
| Modification Type: | Major | Last Reviewed: | 3/25/2005 |
|---|
| Keywords: | kbFAQ kbprb KB177269 |
|---|
|