PRB: CAxWindow Members Can Cause a Memory Leak

This article was previously published under Q229904
This article has been archived. It is offered "as is" and will no longer be updated.
The CAxWindow CreateControl() and AttachControl() functions may leak memory if not used correctly.
The following two techniques of creating ActiveX controls on composite controls (or any window supporting ATL containment) can result in memory leaks.
//Intialize ATL control containment.AtlAxWinInit();//Create container window.HWND hWndCont = m_ax.Create(m_hWnd, rect, 0, WS_CHILD | WS_VISIBLE);//Create & activate ActiveX controlHRESULT hr = m_ax.CreateControl("MSCAL.Calendar");				
//Intialize ATL control containment.AtlAxWinInit();//Create container windowHWND hWndCont = m_ax.Create(m_hWnd, rect, 0, WS_CHILD | WS_VISIBLE);// Create ActiveX control.CComPtr<IUnknown> spunk;HRESULT hr = CLSIDFromProgID(OLESTR("MSCAL.Calendar"), &clsid);hr = CoCreateInstance(clsid, NULL, CLSCTX_ALL, IID_IUnknown, (void**)&spunk);// Activate ActiveX control.HRESULT hr = m_ax.AttachControl(spunk);				
In both techniques, the calls to Create() results in the creation of a CAxHostWindow object. The call to CreateControl() or AttachControl() also creates another CAxHostWindow Object. Upon destruction, the CAxHostWindow object created by Create() is freed.
Use one of the techniques mentioned in article Q218442 to create ActiveX controls at run time.
This behavior is by design.
For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
192560 HOWTO: Adding ATL Control Containment Support to Any Window
218442 HOWTO: Programmatically Add ActiveX Controls to Composite Control

Article ID: 229904 - Last Review: 02/21/2014 00:36:00 - Revision: 3.0

  • Microsoft ActiveX Template Library 3.0
  • kbnosurvey kbarchive kbprb kbctrl kbpending KB229904