KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

Q143108: FIX: Assertion Failed Line 388 of Occmgr.cpp

Article: Q143108
Product(s): Microsoft C Compiler
Version(s): winnt:4.0
Operating System(s): 
Keyword(s): kbole kbActiveX kbCOMt kbContainer kbCtrl kbMFC kbVC400bug kbVC410fix kbGrpDSMFCATL kbN
Last Modified: 14-FEB-2002

-------------------------------------------------------------------------------
The information in this article applies to:

- The Microsoft Foundation Classes (MFC), used with:
   - Microsoft Visual C++, 32-bit Editions, version 4.0 
-------------------------------------------------------------------------------

SYMPTOMS
========

When an MFC 4.0 control container has one or more invisible-at-run-time OLE
controls along with other OLE and non-OLE controls placed on a dialog template,
the following assertion might occur based on the tab-order of the controls in
the dialog:

     Debug Assertion Failed!
     Program: <app name>
     File: occmgr.cpp
     Line: 388

CAUSE
=====

When the MFC framework creates an invisible-at-run-time OLE control, it is
reparented to the desktop window. This makes the control's window not a sibling
of the other windows present in the dialog. Now if this invisible- at-run-time
control has another OLE control (visible at run time) next in tab order, then
the framework places the latter OLE control at the end of the dialog's child
window list. Later when the framework attempts to find the "next" sibling window
of the OLE control (now at the end of the dialog's child window list), it
returns NULL because there is no "next" sibling window to this OLE control.

RESOLUTION
==========

The assertion can be safely ignored, but the tab order will probably be
incorrect. To work around this assertion, place the invisible-at-run-time
controls at the end of the tab order in the dialog template.

STATUS
======

Microsoft has confirmed this to be a bug in the Microsoft products listed at the
beginning of this article. This bug was corrected in Visual C++ 4.1.

MORE INFORMATION
================

The MFC framework creates OLE controls placed on a dialog template resource, if
any, by calling COccManager::CreateDlgControls. This function in turn makes a
call to COccManager::CreateDlgControl to create a specific OLE control. The code
present in CreateDlgControl attempts to setup the tab order of each OLE control
after it is created, for which it calls CWnd::SetWindowPos, passing in the
handle of the window that the control will be inserted after (in the code, this
window is referred to as pWndAfter).

For a clear understanding of what would generate the above described ASSERT,
consider the following reproducible scenario.

Steps to Reproduce the Assertion Failure
----------------------------------------

Create a dialog-based control container application, and place the following
controls with the specified tab order in its main dialog template resource:

- MS-COMM OLE Control (or any invisible-at-run-time control) : 1

- GRID OLE control (or any control that is visible at run time) : 2

- Static control (or any standard Windows control) : 3

- GRID OLE control (or any control that is visible at run time) : 4

Because the MS-COMM OLE control is reparented to the desktop, the GRID control
next to it in the tab order will be created and placed at the end of this
dialog's child window list. Later when the framework creates the final GRID
control, it tries to find the static control that should precede this GRID
control in the Z order, by finding the next sibling window of the second GRID
control. But because there is no next sibling window to the second GRID control,
it returns NULL, which triggers the ASSERT.

Additional query words: kbVC400bug ocx ole control cdk 4.00 4.10

======================================================================
Keywords          : kbole kbActiveX kbCOMt kbContainer kbCtrl kbMFC kbVC400bug kbVC410fix kbGrpDSMFCATL kbNoUpdate 
Technology        : kbAudDeveloper kbMFC
Version           : winnt:4.0
Issue type        : kbbug
Solution Type     : kbfix

=============================================================================

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.