Lesson 1

Most of our time has been spent studying COM's core concepts. We are now moving towards a study of standard COM implementation practices. Most, if not all, COM developers use a development framework to support their development efforts. The most popular C++-based development frameworks are the Microsoft Foundation Classes (MFC) and the Active Template Library (ATL). ATL is the focus of our study. A development framework differs from a class library in that it defines the structure of an application or component. Developers add code by "hooking" the framework. In ATL this means that you provide an application-specific class that derives from classes in the framework, and override virtual functions from the base classes. When the framework code calls these functions, the call is directed into your code. Additionally, ATL requires specific data structures at the global and class levels. ATL makes it very easy to add these structures via a set of high-level macros.
Visual C++ provides code-generators for ATL - an "App-Wizard" and an ATL-class tool. Using these a skeleton COM server and COM object can be created. You can simply fill in the methods generated by the tools. This allows you to concentrate on the details of developing application code, instead of worrying about all the COM and ATL code.
However, I highly recommend that you take the time to understand and differentiate between what the tools do and what ATL does. In other words, analyze the code generated by the tools, try to develop a basic understanding of ATL's core classes and how they support COM. I believe that these efforts will really pay-off when you need to customize and deploy advanced ATL-based COM solutions.

In modules 2 and 3, we studied core COM and implementation practice concepts.
This module discusses how to use the active template library (ATL) to build an in-process server containing a COM object with two interfaces.
At the end of the module, you will be able to:

1. Describe the role of the ATL framework
2. Explain what ATL's core classes do
3. Use the ATL COM-Wizard to generate an in-process COM server
4. Add your own COM implementation classes into the ATL framework
5. Add COM properties and methods into your COM objects

ATL is designed to simplify the process of creating efficient, flexible, lightweight controls. This module leads you through the creation of an ActiveX control, demonstrating many ATL and COM fundamentals.

COM Server is some module of code, a DLL or an EXE, that implements one or more object classes (each with their own CLSID). A COM server structures the object implementations such that COM clients can create an use objects from the server using the CLSID to identify the object through the processes described. In addition, COM servers themselves may be clients of other objects, usually when the server is using those other objects to help implement part of its own objects. This module will cover the various methods of using an object as part of another through the mechanisms of containment and aggregation. Another feature that servers might support is the ability to emulate a different server of a different CLSID. The COM Library provides a few API functions to support this capability that are covered at the end of this module. If the server is an application, that is, an executable program, then it must follow all the requirements for a COM Application as detailed in module 4. If the server is a DLL, that is, an in-process server or an object handler, it must at least verify the library version and may, if desired, insure that the COM Library is initialized. That aside, all servers generally perform the following operations in order to expose their object implementations:

1. Allocate a class identifier-a CLSID-for each supported class and provide the system with a mapping between the CLSID and the server module.
2. Implement a class factory object with the IClassFactory interface for each supported CLSID.
3. Expose the class factory such that the COM Library can locate it after loading (DLL) or launching (EXE) the server.
4. Provide for unloading the server when there are no objects being served and no locks on the server (IClassFactory::LockServer).