Introduction

Did you cheer when you found out that ATL 3.0 would support ActiveX control hosting? I did. This functionality was at the top of my wish list for ATL. ATL 3.0 has finally arrived. What now? In one news group, I saw the following question: "How do I resize ActiveX controls hosted by Composite Control?” The answer to this question is very simple, but the reasoning behind it is not. Therefore, I decided to write this article to share my knowledge of the inner workings of ATL’s hosting of ActiveX controls.

How does ATL implement the hosting of ActiveX controls

If you will look in ATL code, you will notice that code for CComCompositeControl takes less then two hundred lines. How is it possible to fit all hosting support into two hundred lines of code? Well, the answer is quite simple--CComCompositeControl does not have support for ActiveX hosting. The real hero behind the scenes is CAxHostWindow.

CAxHostWindow implements necessary interfaces in order to support the hosting of common ActiveX controls (including windowless) and Microsoft Web Browser control. In case you do not need to host a Web Browser control, you can define _ATL_NO_DOCHOSTUIHANDLER in your project and save about 4K in release dll. CAxHostWindow derives from CWindowImpl, and this means it needs a window to operate. CAxHostWindow can host only one control at a time, and as a result, one CAxHostWindow is required for each hosted control. Without going into all the aspects of implementation (look into atlhost.h for more details), I would like to concentrate here on the way CAxHostWindow handles WM_SIZE and WM_PAINT.

There are two major methods that you can use to support control containment in your control using ATL 3.0. One method is to use the support provided by ATL, namely CAxHostWindow. The other method is to write everything from scratch. By far, using ATL is easier then writing tons of code yourself, but what if CAxHostWindow doesn’t support the functionality that you need? Is following the second method your only option? Most likely, the answer is no. In most cases, the result can be achieved just by extending the functionality of CAxHostWindow, which I will be discussing as the main topic in this article.

The most obvious way to extend the functionality of CAxHostWindow is to modify its code in atlhost.h, but it should be done with care because changes you make will reflect on every user of CAxHostWindow, such as Composite Control. An alternative solution is to derive a new class from CAxHostWindow and override its methods and message handlers. Below, I will demonstrate in more detail how to modify CAxHostWindow to support new functionality.