ATL's Control Containment Limitations ATL introduced COM control containment in Version 3.0. Although several significant bugs have been fixed and the control-containment code is very capable, it's not quite all you might like. Several limitations affect the way that ATL implements control containment: All the control-hosting interfaces are exposed by a single class, CAxHostWindow, which acts as the site, the document, and the frame. The actual implementations of some of the hosting interfaces are split into other classes, but there are no template parameters or runtime variables that you can change to pick a different implementation. If you contain multiple controls, you get duplicate implementation of interfaces that could have been shared. This is particularly cumbersome if the control asks for the HWND for the document or the frame. Instead of allowing the client application programmer to designate his own document or frame window, ATL creates a new window, resulting in potentially three container windows per control. If the control creates its own window, that's four windows instead of just one, to host a single control. Each control must have its own window on the container side for the CAxHostWindow object to work with. Even a windowless control has one window associated with itnot exactly the windowless-ness for which one would hope. Finally, unlike the rest of ATL, the control-containment architecture is not well factored. You can't easily reach in and change how one piece works without also changing the other pieces. For example, if you want to have a shared frame for all the control sites, you have to replace CAxHostWindow (probably by deriving from it) and also change how CAxWindow hooks up the control site so that it uses your new class. Ideally, we would like to override some CAxHostWindow members but still be able to use the rest of the containment framework as is.
What do these limitations mean to you? For a lot of the work you're likely to do with control containment, not much. This chapter has shown you the considerable use to which you can put ATL's control-containment framework. However, if you're looking for the C++ equivalent of a general-purpose, full-featured control container such as Visual Basic, ATL isn't quite there.[13] [13] For more information about bringing ATL's COM control containment up to snuff, read "Extending ATL 3.0 Control Containment to Help You Write Real-world Containers" (MSJ, December 1999), at www.microsoft.com/msj/1299/Containment/Containment.aspx (http://tinysells.com/61).
|
