PRB: Windowless ATL, MFC Controls Work in Internet Explorer 3, Fail in 4.0

ID: Q194220

The information in this article applies to:

Microsoft Internet Explorer (Programming) versions 4.0, 4.01, 4.01sp1, 5.0
The Microsoft Active Template Library (ATL) 3.0, included with:
- Microsoft Visual C++, 32-bit Editions, versions 5.0, 5.0sp1, 5.0sp2, 5.0sp3, 6.0
The Microsoft Foundation Classes (MFC), included with:
- Microsoft Visual C++, 32-bit Editions, versions 5.0, 5.0sp1, 5.0sp2, 5.0sp3, 6.0

SYMPTOMS

The debug build of an ActiveX control written in MFC or ATL displays an ASSERT on a line in MFC:


ASSERT(::IsWindow(m_hWnd));

In ATL the following appears:


ATLASSERT(::IsWindow(m_hWnd));

A release build of the ActiveX control may crash with an Access Violation or not work properly.

Also, the COleControl::OnCreate or WM_CREATE message handler for the control may unexpectedly fail to fire.

These symptoms occur specifically when the control is hosted in Internet Explorer 4.0x or later but do NOT occur when the control is hosted in Internet Explorer 3.0x.

CAUSE

The ActiveX control has been declared to be windowless but calls framework functions that require a window or the control otherwise assumes the existence of a window. The OnCreate method is called only when a window is created, and code in this method will not execute if the control is windowless.

Internet Explorer 3.0x is not a windowless control container, so windowless controls get created with a window anyway when hosted in HTML pages. Internet Explorer 4.x is, on the other hand, a true windowless control container. The mistake in the control is hidden by Internet Explorer 3.0x's container support, only to be revealed when tested against Internet Explorer 4.0x or later.

ATL controls are windowless by default. In ATL, it is much easier for a control author creating a control for Internet Explorer 3.0x to code the entire control under the mistaken assumption that the control is windowed.

MFC controls are windowed by default, but based on the choices made during the Control Wizard, could be accidentally set to be windowless.

RESOLUTION

Move necessary code out of the OnCreate/WM_CREATE handler and redesign the control to not require a window. Do not call MFC or ATL functions that require windows, particularly those that result in the ASSERT described in SYMPTOMS above.

-or-

Change the control to be windowed instead of windowless. In an ATL control, set CComControlBase::m_bWindowOnly to TRUE in the CComControl object's constructor. In an MFC control, remove "windowlessActivate" from the dwFlags enumeration returned from the GetControlFlags method.

The latter is preferred because by the time this problem is observed, the control has probably already been coded from the ground up to assume the existence of a window.

STATUS

This behavior is by design.

MORE INFORMATION

This article equally applies to any other windowless control container.

If the ActiveX control is not marked as windowless but still shows similar problems when hosted in Internet Explorer 4.0x or later, it is a different issue from the one discussed in this article.

REFERENCES

For additional information, please see the following article in the Microsoft Knowledge Base:

Q195188 PRB: ActiveX Control Window is not Created Until Visible in IE

For more information, please see the MSDN Web Workshop:

http://msdn.microsoft.com/workshop/default.asp

Additional query words:

Keywords : kbActiveX kbCtrl kbIE400 kbIE401 kbMFC kbVC500 kbVC600 kbATL300 kbIE401sp1 kbIE500
Version : WINDOWS:3.0,4.0,4.01,4.01sp1,5.0; winnt:5.0,5.0sp1,5.0sp2,5.0sp3,6.0
Platform : WINDOWS winnt
Issue type : kbprb