PRB: Windowless ATL, MFC Controls Work in Internet Explorer 3, Fail in 4.0 (194220)
The information in this article applies to:
- Microsoft Internet Explorer (Programming) 4.0
- Microsoft Internet Explorer (Programming) 4.01
- The Microsoft Active Template Library (ATL) 3.0, when used with:
- Microsoft Visual C++, 32-bit Enterprise Edition 5.0
- Microsoft Visual C++, 32-bit Professional Edition 5.0
- Microsoft Visual C++, 32-bit Enterprise Edition 6.0
- Microsoft Visual C++, 32-bit Professional Edition 6.0
- Microsoft Visual C++, 32-bit Learning Edition 6.0
- The Microsoft Foundation Classes (MFC), when used with:
- Microsoft Visual C++, 32-bit Enterprise Edition 5.0
- Microsoft Visual C++, 32-bit Professional Edition 5.0
- Microsoft Visual C++, 32-bit Enterprise Edition 6.0
- Microsoft Visual C++, 32-bit Professional Edition 6.0
- Microsoft Visual C++, 32-bit Learning Edition 6.0
This article was previously published under Q194220 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:
195188 PRB: ActiveX Control Window is not Created Until Visible in IE
For more information about developing Web-based solutions for Microsoft Internet Explorer, visit the following Microsoft Web sites:
| Modification Type: | Major | Last Reviewed: | 5/11/2006 |
|---|
| Keywords: | kbCtrl kbprb KB194220 |
|---|
|