List of Figures

---

Chapter 1: A Review of Classic Object-Oriented Programming

Figure 1-1: Internal organization of an SP application.

Figure 1-2: Creating a new Win32 Console Application.

Figure 1-3: The CarInC application.

Figure 1-4: Altering data can result in logical errors.

Figure 1-5: Merging related global data into a C structure.

Figure 1-6: Merging related data and related functionality into a C++ class.

Figure 1-7: Each instance of a class typically maintains a unique state.

Figure 1-8: Safe access to the private sector of a class.

Figure 1-9: Accessing the New Class Wizard.

Figure 1-10: The Visual C++ New Class Wizard.

Figure 1-11: The C++ car application.

Figure 1-12: Classical inheritance suggests an Is-A relationship.

Figure 1-13: Containment of objects.

Figure 1-14: Shape class with a virtual Draw() method.

Figure 1-15: The employee class hierarchy.

Figure 1-16: vPtr/vTable relationship for CFTEmployee.

Figure 1-17: Ad hoc polymorphism.

Figure 1-18: A VB form object serves as the main window.

Figure 1-19: VB program output.

Figure 1-20: Using the New Class Wizard to derive a new class.

Figure 1-21: The completed employee application.

Figure 1-22: Template output.

Chapter 2: Interface-Based Programming

Figure 2-1: A class with a single public interface.

Figure 2-2: A massive public interface, listed by related functionality.

Figure 2-3: Factoring a single interface into discrete interfaces.

Figure 2-4: Our C3DRect class.

Figure 2-5: Internal layout of C3DRect supporting two interfaces.

Figure 2-6: Polymorphism with IDraw.

Figure 2-7: Layout of IDraw2.

Figure 2-8: Layout of IDraw3.

Figure 2-9: Non-standard versioning == loss of polymorphism.

Figure 2-10: A hierarchy of related interfaces.

Figure 2-11: Drawing interface hierarchy.

Figure 2-12: Interface client version two.

Figure 2-13: The final client.

Chapter 3: The Component Object Model

Figure 3-1: Client and server relationships.

Figure 3-2: The in-process relationship.

Figure 3-3: The local (out-of-process) relationship.

Figure 3-4: The remote relationship.

Figure 3-5: CoCar is contained by CoHotRod.

Figure 3-6: CoHotRod exposing the inner object’s interfaces as its own.

Figure 3-7: A COM object must support IUnknown.

Figure 3-8: The guidgen.exe utility.

Figure 3-9: Fields of the 32-bit HRESULT.

Figure 3-10: The Error Lookup utility.

Figure 3-11: Configuration to view Unicode strings.

Figure 3-12: The result of enabling Unicode string debugging.

Figure 3-13: The “almost real COM” application.

Figure 3-14: Class objects create related coclasses.

Figure 3-15: DllGetClass-Object() exposes class factories.

Figure 3-16: The Registry Editor.

Figure 3-17: ProgIDs map to CLSIDs.

Figure 3-18: HKCR\CLSID maps to ProgIDs andthe server’s physical path.

Figure 3-19: ProgID listing for CoHexagon.

Figure 3-20: A path to shapes.dll, listed under HKCR\CLSID.

Figure 3-21: New Win32 DLL CASE tool.

Figure 3-22: The “repaired” ClassView.

Figure 3-23: SCM, ole32.dll, the client, and your server.

Figure 3-24: Specifying a COM DLL debugging host.

Figure 3-25: Who says you can’t get satisfaction?

Chapter 4: Type Information and Language Independence

Figure 4-1: A VB definition of the custom IShapeEdit interface.

Figure 4-2: Be sure to deselect the MkTypLib compatible option.

Figure 4-3: MIDL-generated output files.

Figure 4-4: HKCR\TypeLib entries for our Shape server type information.

Figure 4-5: The various nodes of the OLE/COM Object Viewer.

Figure 4-6: Expanding on a coclass will activate the object.

Figure 4-7: Preparing to examine an object’s IDL code.

Figure 4-8: The VB References dialog.

Figure 4-9: The VB Object Browser.

Figure 4-10: J++ COM Wrappers dialog box.

Figure 4-11: IDL constructs end up as Java proxy classes.

Figure 4-12: The Java Object Browser.

Figure 4-13: Bringing our type informa- tion into VB.

Figure 4-14: The GUI design of our VB client.

Figure 4-15: J++ New Project workspace.

Figure 4-16: J++ Form layout for CoCar client.

Figure 4-17: Java client using our C++ COM server.

Chapter 5: Type Information and Location Transparency

Figure 5-1: In-proc servers offer a fast though less robust connection.

Figure 5-2: Clients and local servers communicate through stubs and proxies.

Figure 5-3: Remote invocations require DCOM’s underlying RPC protocol.

Figure 5-4: Proxies support IRpcProxyBuffer, which allows them to communicate to the channel object. The channel object supports IRpcChannel- Buffer, which packages up method requests.

Figure 5-5: The proxy manager aggregates all proxies into a whole, simulating the distant coclass.

Figure 5-6: Stubs implement IRpcStubBuffer to unpackage the request and hand it off to the real COM object.

Figure 5-7: The movement of remote interface method invocations.

Figure 5-8: AppIDs identify the entire COM application.

Figure 5-9: HKCR\AppID holds all registered COM applications.

Figure 5-10: The DllSurrogate value under an AppID listing specifies who should host legacy in-proc servers.

Figure 5-11: Each CLSID in a COM application maps to the same AppID.

Figure 5-12: Configuring a DLL to use dllhost.exe

Figure 5-13: The generated AppID entries.

Figure 5-14: A running surrogate process and launching client.

Figure 5-15: The global methods of your *_p.c MIDL- generated file.

Figure 5-16: Configuring the preprocessor to build your stub and proxy.

Figure 5-17: Linking to the RPC libraries.

Figure 5-18: Registering your stub and proxy DLL.

Figure 5-19: HKCR\Interface listing for IClassFactory.

Figure 5-20: Ole32.dll: The core standard interface marshaler.

Figure 5-21: CLSID of the universal marshaler.

Figure 5-22: A custom interface registered under HKCR\Interface.

Figure 5-23: Referencing our local CoCar from VB.

Figure 5-24: A given AppID may have a RemoteServer-Name value specifying a remote machine.

Figure 5-25: CLSID listing should have a corresponding AppID value.

Figure 5-26: The Applications tab allows you to edit the security and activation values for a given COM application.

Figure 5-27: You may specify default client security checks using the Default Properties tab.

Figure 5-28: You may apply machine-wide DCOM security settings with dcomcnfg.

Figure 5-29: Location of all default security settings for a particular machine.

Figure 5-30: Managing authentication at the AppID level.

Figure 5-31: ACLs may be established for access, launch, and configuration permissions using dcomcnfg.exe. You have the choice of default machine-wide settings or AppID-specific setting.

Figure 5-32: Access control for HKEY_CLASSES_ROOT\AppID\{C8376C06-F1FA-11d2-B8E0-0020781238D4} (CoCar).

Figure 5-33: Editing the RemoteServer-Name value for a given AppID.

Figure 5-34: Setting universal access to a COM server.

Figure 5-35: The Interactive User is the only identity that allows the server to show any GUI element.

Figure 5-36: Specifying the remote server.

Figure 5-37: Reset the location of the DCOM server.

Figure 5-38: From C structure to DCOM server in five easy chapters.

Chapter 6: An Introduction to the Active Template Library

Figure 6-1: Behold ATL.

Figure 6-2: Creating a new ATL project workspace.

Figure 6-3: The ATL COM AppWizard is used to generate boilerplate code for your component housing.

Figure 6-4: Including dlldatax.c into your project’s build.

Figure 6-5: Removing precompiled header dependencies from dlldatax.c.

Figure 6-6: The final step to merge your stub/proxy DLL: define the preprocessor symbol _MERGE_PROXYSTUB.

Figure 6-7: New Project confirmation dialog.

Figure 6-8: Your initial ATL DLL project.

Figure 6-9: Default ATL resources.

Figure 6-10: Registering a DLL with regsvr32.exe

Figure 6-11: Registering an EXE server at the command line.

Figure 6-12: Accessing the Object Wizard.

Figure 6-13: The ATL Object Wizard allows you to insert COM objects into component housing generated by the ATL COM AppWizard.

Figure 6-14: Types of ActiveX controls supported by ATL 3.0.

Figure 6-15: Configuration options for an ATL Simple Object.

Figure 6-16: Attributes for a Simple Object.

Figure 6-17: Navigating ATL source code with the ClassView tab.

Figure 6-18: The “REGISTRY” resource holds the RGS binaries for an ATL server.

Figure 6-19: Accessing the Add Method Wizard.

Figure 6-20: Adding methods to your interfaces.

Figure 6-21: Adding additional method attributes.

Figure 6-22: The Implement Interface Wizard.

Figure 6-23: Implementing interfaces defined outside your project.

Figure 6-24: A Visual Basic class defining a single property.

Figure 6-25: The Add Property Wizard.

Figure 6-26: ATLTRACE output.

Figure 6-27: _ATL_DEBUG_QI output.

Figure 6-28: _ATL_DEBUG_QI only uses friendly names for registered interfaces.

Figure 6-29: _ATL_DEBUG_INTERFACES also displays reference counts.

Figure 6-30: The initial ATL COM AppWizard exports.

Figure 6-31: Changing the suggested name for the [default] interface.

Figure 6-32: Adding methods à la ATL.

Figure 6-33: Don’t forget to specify parameter attributes!

Figure 6-34: Don’t forget to recompile your type library first.

Chapter 7: ATL COM Objects and COM Exceptions

Figure 7-1: Enabling project browsing.

Figure 7-2: The Developers Studio Browse window.

Figure 7-3: Each thread in a process receives local storage but shares global data.

Figure 7-4: When multiple threads access global data not secured by a Win32 locking primitive, bad things happen.

Figure 7-5: The thread-safe FOOFIGHTER.

Figure 7-6: Multiple threads must wait in line to access objects in an STA.

Figure 7-7: Objects in the MTA can be accessed by multiple threads at once.

Figure 7-8: In-process servers advertise their threading preference with the Threading- Model value.

Figure 7-9: Intra-apartment calls entail stubs and proxies.

Figure 7-10: ATL coclasses support all of COM’s threading models.

Figure 7-11: The derivation of an ATL Simple Object.

Figure 7-12: C++ client catching our COM exception.

Figure 7-13: VB client catching our COM exception.

Figure 7-14: Specifying ATL support for COM exceptions.

Chapter 8: COM Object Identity and ATL

Figure 8-1: A familiar- looking coclass, exposing three interfaces.

Figure 8-2: Making use of nested classes.

Figure 8-3: A hierarchy of related interfaces.

Figure 8-4: CoSportsSedan supports two interfaces derived from ICar.

Figure 8-5: CoColor is contained by CoHexagon.

Figure 8-6: The result of our IDL configuration.

Figure 8-7: COM aggregation.

Figure 8-8: Configuring aggregation support.

Figure 8-9: Start your engines!

Chapter 9: Component Housing and ATL

Figure 9-1: The registration macros typically make use of resource IDs.

Figure 9-2: The registry holds all component categories in a unique subkey.

Figure 9-3: Registered COM categories.

Figure 9-4: The safe for scripting COM category.

Figure 9-5: A given coclass lists the categories to which it belongs.

Figure 9-6: Result of the custom category map.

Figure 9-7: The drawable objects.

Figure 9-8: A very flat object model.

Figure 9-9: A slightly deeper object model.

Figure 9-10: Conflicting GUIDs.

Figure 9-11: The Named Drawing Objects.

Figure 9-12: Results of our custom UpdateRegistry() logic.

Figure 9-13: Yet another VB test client.

Figure 9-14: Interacting with the COM category manager.

Figure 9-15: The Named Drawing Objects launcher utility.

Chapter 10: Scriptable Objects and ATL

Figure 10-1: Late binding using IDispatch.

Figure 10-2: Late binding using MS Internet Explorer and VBScript.

Figure 10-3: Creating a new Dev Studio Macro.

Figure 10-4: Describing the macro.

Figure 10-5: Automation, vTable, and dual interface objects.

Figure 10-6: Keep it simple.

Figure 10-7: Bootstrapping the COM library via MFC.

Figure 10-8: Inserting a new COleDispatch-Driver class into an MFC project.

Figure 10-9: Specifying a dual interface with ATL.

Figure 10-10: Not safe for scripting! Need more GUIDs.

Figure 10-11: Got the GUIDs; safe for scripting (and initializing).

Figure 10-12: A web-based CoCar client.

Chapter 11: COM Enumerators and COM Collections

Figure 11-1: Working with a safe array of BSTRs.

Figure 11-2: A C++ enumeration client.

Figure 11-3: The core ATL enumerator templates.

Figure 11-4: Using a collection of COM objects.

Figure 11-5: Using our initial collection.

Figure 11-6: Grab the squiggles!

Figure 11-7: Squiggle driver.

Chapter 12: Callback Interfaces and Connectable Objects

Figure 12-1: A coclass with four inbound interfaces.

Figure 12-2: Polling an object is a waste of time and energy.

Figure 12-3: Bidirectional communication using a callback interface.

Figure 12-4: Implementing an interface in Visual Basic.

Figure 12-5: The sink is responsible for implementing outbound interfaces.

Figure 12-6: A generic example illustrating COM’s generic connectable architecture.

Figure 12-7: Events of the [default, source].

Figure 12-8: Enabling your object to function as a connection point container.

Figure 12-9: Generation of a complete implementation of a connection object à la ATL.

Figure 12-10: Set your timer object to an interval of 500.

Figure 12-11: The VB sink is alive and kicking.

Figure 12-12: The C++ sink at work.

Chapter 13: Using ATL as a Windowing Framework

Figure 13-1: A simple Win32 window.

Figure 13-2: The ATL windowing hierarchy.

Figure 13-3: The ATL Add Windows MessageHandler Wizard.

Figure 13-4: An ATL-based window.

Figure 13-5: Tweaking WNDCLASSEX in ATL.

Figure 13-6: Inserting a new Dialog resource.

Figure 13-7: Inserting a dialog box using the ATL Object Wizard.

Figure 13-8: Designing an interactive dialog.

Figure 13-9: Responding to BN_CLICKED.

Figure 13-10: The 8-Ball never lies.

Figure 13-11: Our custom icon.

Figure 13-12: A simple test menu.

Figure 13-13: A simple About box.

Figure 13-14: A VB tester application.

Figure 13-15: CMyWindow in action.

Chapter 14: Developing ActiveX Controls with ATL

Figure 14-1: A palette of ActiveX controls.

Figure 14-2: Inserting additional ActiveX controls in VB.

Figure 14-3: The MS Calendar Control.

Figure 14-4: Property pages for the MS Calendar control.

Figure 14-5: An invisible at runtime control.

Figure 14-6: Available control selections as of ATL 3.0.

Figure 14-7: Setting the names for ShapesControl.

Figure 14-8: Enabling connection points for ShapesControl.

Figure 14-9: ActiveX controls have additional settings above and beyond a simple coclass.

Figure 14-10: Stockproperties of ShapesControl.

Figure 14-11: Additional registration details for an ActiveX control.

Figure 14-12: The initial toolbox image.

Figure 14-13: Our updated toolbar bitmap image.

Figure 14-14: Hunting down our control from the OLE/COM Object Viewer.

Figure 14-15: Adding the initial custom ShapeType property.

Figure 14-16: Our custom ShapeType property.

Figure 14-17: Exercising our properties.

Figure 14-18: Responding to the custom event.

Figure 14-19: The custom About box for ShapesControl.

Figure 14-20: The VB client.

Figure 14-21: Our control is in charge of supplying the window, and may be inserted as an embedded object.

Figure 14-22: IDB_LEMON1

Figure 14-23: IDB_LEMON2

Figure 14-24: IDB_LEMON3

Figure 14-25: IDB_ALMOST-BLOWNUP

Figure 14-26: IDB_BLOWNUP

Figure 14-27: IDD_ABOUTBOX

Figure 14-28: This will trigger the code in your AboutBox() method.

Figure 14-29: Inserting our control.

Figure 14-30: The VB test client.

Figure 14-31: Approaching critical speed!

Figure 14-32: Two competing fonts.

Figure 14-33: One unified font.

Figure 14-34: Inserting a new property page à la ATL.

Figure 14-35: The text in the Title selection will be the string used on the tab for your custom page.

Figure 14-36: The GUI of our custom property page.

Figure 14-37: The effects of clicking the Apply button should affect all selected controls.

Figure 14-38: The custom page in action.

Figure 14-39: Hosting ShapesControl in IE.

Figure 14-40: Using our property bag support.

Figure 14-41: Capturing our event in VBScript.

Figure 14-42: The result of not having a valid *.lic file.

Figure 14-43: A custom property page.

Figure 14-44: Launching our page.

Figure 14-45: Inserting our CAxCar into MS Word.

---