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.
|
