PRB: COleServerDoc Calls CoLockObjectExternal When Displaying a View (297130)
The information in this article applies to:
- Microsoft Visual Studio, Enterprise Edition 6.0
This article was previously published under Q297130 SYMPTOMS
If a Microsoft Foundation Classes (MFC) document view architecture-based executable file is automated, the view can be displayed to the user through Automation, usually by adding a Visible property that the client can set to TRUE, enabling the server to make its windows visible in response. When this occurs, MFC places the server under user control by calling AfxOleSetUserCtrl(TRUE). When the last reference count is released, MFC will shut down the application only if the application is no longer under user control, so the standard practice is to call AfxOleSetUserCtrl(FALSE) when the window is no longer visible.
When the server's document class is based on COleServerDoc, this technique is ineffective, and the server remains in memory.
CAUSE
A COleServerDoc-based document class makes a call to CoLockObjectExternal when its views are made visible. The syntax of the call is effectively CoLockObjectExternal(lpUnk, TRUE, TRUE). This means that the object is locked in memory independent of external AddRef/Release operations. As a result, the object stays in memory until this call is undone.
RESOLUTION
The way to work around this problem is to call CoLockObjectExternal, passing FALSE as the second parameter when the views are no longer visible. MFC provides a wrapper function called LockExternal to simplify this call. The syntax to unlock the server would be:
LockExternal(FALSE, TRUE);
Another approach, which may be simpler but could introduce potential complications, would be to override the OnShowViews function in the document class. The default for this function is to call UpdateVisibleLocks, which eventually calls CoLockObjectExternal only when a view is visible. This is correct for an embedding scenario, which is what COleServerDoc is designed to manage, but in Automation the matching call is made after the view has been hidden, so the corresponding call to undo the lock is never made. One approach would be to simply call UpdateVisibleLocks unconditionally, regardless of whether the view is visible.
Another approach would be to do nothing and leave the OnShowViews overridden function empty. These overrides could present problems in an embedding scenario, however, and are not recommended. Adding a call to LockExternal (or UpdateVisibleLocks) in the Automation method, as described earlier, would be preferable.
STATUS
This behavior is by design. It is standard, recommended practice for object servers.
REFERENCES
See the following Visual C++ Programmer's Guide topics:
For sample code to use with generic MFC automation servers, see the following Microsoft Knowledge Base article:
140591 HOWTO: Display an MFC Automation Document Automatically
Modification Type: | Minor | Last Reviewed: | 8/15/2005 |
---|
Keywords: | kbAutomation kbDocView kbprb KB297130 |
---|
|