Developers Workshop to COM and ATL 3.0
|
| < Free Open Study > |
|
Physically, ATL is not much more than a number of header files (and a few CPP files) installed under the ATL\Include subdirectory of MS Visual Studio (see Figure 6-1).
As we will be digging into a number of these files throughout the remainder of this book, the following table presents a roadmap describing the sort of code you can expect to find in the ATL file set (grouped by related functionality):
| ATL Source Code File | Meaning in Life |
|---|---|
| <atlwin.h> <atlwin.cpp> <atlhost.h> | ATL's support for window and dialog development. <atlhost.h> is new to ATL 3.0, which defines support for building ActiveX control host windows. |
| <atldb.h> <atldbcli.h> <atldbsch.h> | OLE DB support. |
| <atlsnap.h> | ATL's support for MMC Snap In development. |
| <atlctl.h> <atlctl.cpp> | ATL's support for ActiveX control development. |
| <atliface.idl> <atliface.h> | IDL code for ATL-defined COM interfaces and the MIDL-generated header file. |
| <altconv.h> <atlconv.cpp> | Defines a number of conversion functions and macros to work with COM string manipulation. |
| <atldef.h> | ATL preprocessor symbols (#defines). |
| <statreg.h> <statreg.cpp> | ATL support for self-registration. |
| <atlbase.h> | The core ATL file that defines the framework support for your COM servers, COM wrapper classes, and debugging aids. |
| <atlcom.h> | Support for IUnknown, automation, enumerators, and COM persistence. Aggregation support, default class objects, and COM map macros are also defined in <atlcom.h>. |
| <atlimpl.cpp> | Implementations of various ATL classes. Heap allocation operators (used if you choose not to link to the C runtime). |
For the most part, the correct files will be included into your project based on the configuration of the ATL COM AppWizard and the type of coclass selected from the ATL Object Wizard. At times, however, you will need to include various files manually, as ATL attempts to include the minimal and complete set of header files. For example, unless you are developing an inherently GUI-based coclass (such as an ActiveX control), you cannot access the Windows support provided by <atlwin.h> until you include this file in your precompiled header.
The Division of Labor: ATL and You
When developers make the choice to leverage existing code provided by a framework, the first task is to understand where the framework support ends and your work begins. ATL is a component framework comprised of a number of wizards, C++ templates, classes, and macros. The framework provides implementations for many standard COM interfaces, server housing support, and various types of coclasses. Furthermore, a coclass may support any number of ATL-supplied COM services, such as connection points, COM error support, threading models, and so on.
However, ATL can only take you half the way home. ATL has little idea what your specific programming tasks will entail. Therefore, while ATL can most certainly provide support for the necessary COM goo most solutions require, you pick up the ball and extend the wizard-generated code to finalize your COM project for your specific needs.
You will still be required to provide the following: First off, you cannot escape a solid understanding of COM itself. If you read the first five chapters in this book, you are in a perfect position to leverage ATL. Next, ATL does not remove you from writing IDL code. While the ATL wizards set up minimal IDL code in many ways, you will still need to define all your COM interfaces in IDL syntax.
Finally, as you have made the choice to leverage a component framework, you now have an additional responsibility: You need to understand the ATL framework. As previously mentioned, this chapter gives you the minimal and complete set of tools to build ATL COM servers. The next several chapters will dive headlong into the inner workings of ATL, as well as introduce more advanced COM and ATL topics.
|
| < Free Open Study > |
|