"ATL INTERNALS" book review. Pan Aimin

Pan Aimin offers 2000/06/12 without any institution or individuals to be reproduced or copied in any way.

ATL's deep-in-depth introduction to the book "ATL INTERNALS" Pan Aimin, May 7, 2000 Beijing University Computer Research Institute, 100871 Introduction In the face of the prosperity of computer book market, I often lane computer development technology today. How lucky is the same? Ten years ago, we are very easy to learn computer languages. To master a variety of development tools, only relying on your own exploration and very small reference manual. I remember that when I learned Visual C and MFC in 1994, I only rely on the software that comes with the online help; now the situation is different, the computer book in the bookstore is full of books on the books of Visual C and MFC. There are several editing friends to advise me to write a little book, I think it is necessary, because Visual C has a lot of books, it is almost all books that are suitable for a variety of readers, and there are some books. Still quite good. However, in 1998, I feel too little about COM books, so I don't have determined, I wrote a book about COM, and published by Tsinghua Publishing House at the end of 1999. Soon, there are many books on COM, and some foreign books have also introduced to the country. From the perspective of computer development technology history, a technology will introduce a lot of books, then this technology will soon become popular, otherwise it will be difficult to promote. Speaking COM, I believe that friends who have developed experienced experience in the Windows platform have been exposed, it is the basic software model of the Windows operating system. Since the establishment of 93 years, it has made an indelible contribution to the promotion and development of the Windows platform. And it is still growing. But to truly develop COM components is not very easy, in Visual C , we can use both MFCs or use ATL. The MFC is fully facing the Windows application. It has established a C class library suitable for developing Windows applications with C encapsulation technology. Although MFC provides a large number of COM support in the later version, the basic design structure, MFC Not suitable for developing professional COM components, it is suitable for providing corresponding COM support on the basis of Windows applications. ATL is different from MFC, which is completely to the COM component, and its technical route is different from MFC. The MFC uses conventional technologies such as inheritance, encapsulation, nested in C , and ATL uses advanced technologies such as C . And even used STL. So learning and using ATL requires us to be familiar with these C advanced features. On the other hand, the ATL structure is completely targeted in COM, which requires the user to know the COM specification, so it is possible to truly use the ATL. Although there are current books about MFC, it is very small books that fully introduce ATL, even at all, this can't be said to be a regret. I have been fortunate to see an ATL's English original book "ATL INTERNALS" in February this year. This article will introduce this book. Before watching this book, I have a basic understanding of ATL. Due to the need for writing at the end of 1998, I have read the partial source of ATL, and it is clear for the basic structure of ATL. When I first saw this book, I quickly read a chapter. I didn't feel how good this book was, and I haven't been leisure because of my busy reasons, until recently, I read this book carefully. It feels that this is a good book.

I used to read the books of the development technology class carefully. One is because I have a slow reading, and the second is that the books often have a book that is not worth reading. But this book I read very carefully, because this book puts almost all of the ATL's essence, many of the contents of the ATL can make you heart, as a programmer, this is also a chance of learning and improvement . I wrote this article is not just to introduce this book to the reader, I also hope to share my experience in reading the process of reading. At the same time, I also hope to be able to introduce you to the structure and mechanism of ATL according to the route of this book. Preparing to read "ATL INTERNALS" by Addison-Wesley Press, the author is Brent Rector and Chris Sells, published in February 1999, a book more than 600 pages. About the background knowledge of this book may be very interesting to many COM hamagumes. First, the preamble of this book is written by ATL inventor Jim Springfield. In the preface, JIM introduces the history of ATL. For the content introduced in the book, I will praise "I can learn a lot of reading. The content can't be mastered by the source code ", in the last, JIM also talked about the future of ATL. Second, in the authors written in the authors, they mentioned that ATL is inseparable from COM. If you want to master the ATL, you must first grasp COM. ATL is a framework that produces C / COM code, just as a C language is a framework that produces assembly code, this point of view is quite novel, and it is true that it is true. The author specially recommended Don Box's book "Essential COM", in English book, the COM book is a lot, which shows that the relationship between the two authors and DON BOX is not in general. I remember that Don Box has also recommended this book this book. If the reader has the opportunity to see the book review of this book (www.amazon.com), you can know that there is a close relationship between them. One of the Chris Sells, one of Don Box and the other two, wrote a book "Effective COM" (there are many items in this book). I believe that their instructions are based on the absolute understanding of each other. They are all COM top masters, but also the top masters of ATL, readers often see their articles in MSJ (Microsoft System Journal). As the author, read this book requires strong preparatory knowledge, according to the understanding after I read this book, readers should have the following preparation knowledge before reading this book:

Be sure to understand COM. ATL is completely targeted for COM, and many details are designed to better achieve COM. If the reader only reads "INSIDE COM" (COM technology insider "published by Tsinghua University Press), then if you want to read" ATL INTERNALS "is not enough, it is recommended that the reader is looking for another information. Be sure to understand C template technology. ATL fully utilizes the advantages of the template, and its entire architecture is completely established on the template. If the reader is not familiar with the template, then it is almost unable to read the ATL. Basically, STL (optional). ATL's collection class and enumeration class use STL, of course, if the reader does not understand STL, basically does not affect the global understanding, but the thinking of the container in STL is connected to the ideology of the COM collection, ATL puts the two organically unified Woke up. So, "ATL INTERNALS" is a very high book because ATL is a high starting point. As far as I know, there are now many programmers already use ATL. This is a good phenomenon, indicating that our domestic programmers are quite high, although our information is not rich enough (at least for ATLs), but We still follow these new technologies. Despite this, if you want to truly use ATL, you must understand the mechanism of ATL, which is different from the MFC. If we don't understand the mechanism of MFC, you can make good programs, using MFC, can provide OLE support. ATL requires us to adjust its class very well, select the appropriate template class as needed, and to correct its behavior if necessary. ATL has already reached a version 3.0, but there is still a lot of mistakes, this book has pointed out some mistakes, but I believe that there will be more mistakes, which makes a higher demand for programmers, it is true. Therefore, the conclusion is: use ATL must understand ATL! Although I said this, I still think that ATL is a good technology and is a good COM template library. And I also deeply feel the importance of the ATL programmer, and some things cannot be obtained from the source and reference manual. Since I have seen this good book, then I should introduce this book, let everyone know this. This book. Also let everyone share my experience. If there is a publishing agency to introduce this book, it is our great ATL programmer's gospel. The content introduction I will introduce the contents of ATL according to the "ATL INTERNALS" narrative order. I hope that readers can not only understand the content of this book, but also learn about the mechanism of ATL. The original book includes 11 chapters, I divide this 11th chapter into four parts according to the content introduced in each chapter. The first part of the ATL use and features show this part of the space, only a short chapter content, read very easy. At the beginning, I thought that all books were like this, so I feel that this is also a book of the nature of the guidelines. At that time, I didn't pay much attention. In this chapter, the author briefly introduces the concept of ATL, and then creates a COM service program with APWIZARD and ATL Object Wizard and the process of COM object classes. The meaning of each option in Wizard is described by item. With the basic engineering framework and object class framework, the author starts to show some of the other features of the ATL:

Add attributes and methods. Add additional interfaces. Provide scripting support. Provide permanent characteristics and increase permanent interfaces. Join the event support, using COM's connectable object features. Support for windows. Implement component category support. Increase user interface characteristics, develop ACTIVEX control with ATL. How to incline to ActiveX control. The author introduces these content very simple, but it is possible to have some basic impression that there is a clear idea for ATL before reading follow-up. If the reader is familiar with COM and have experienced ATL development experience, reading this part will be very easy. The second part of the ATL implementation COM: Basic section This section describes the basic method of ATL implementation COM, including four chapters, as follows: ATL Smart Types, Objects in ATL, COM Servers, Interface Maps. These four chapters are the essence of ATL, and it is also the essence of this book. If all the contents of the book are readable, then this part is not read. The second chapter describes the intelligent type of ATL, including string type, Variant type, and interface pointer type. The COM specification requires all characters to use double-byte characters, not our common ANSI characters, so the processing of strings is often the task that must be faced in our programming work, although there is not much difficult, but often Flower off us to deal with these trivia. The author first introduces many concepts related to character expressions and a variety of conversion channels, and then introduces the basic character type encapsulation class CCOMBSTR and CComvariant. Author's introduction to these two classes is very meticulous, pointing out some details of each member function, or even individual defects. When I read, I am very interested in this part, although I basically know that each member function can also get the details of the ATL's source code, but read still feels a lot. In turn, this chapter is the intelligent pointer class, my interest is not big, probably the reason why I have been biased with the smart pointer, but the smart pointer is used very widely in the ATL. Application of intelligent pointer is available everywhere. ATL's smart pointer package class is a relatively typical, functional comprehensive smart pointer template class, interested readers to read the source of these two classes (CComptr and CCOMQIPTR). The first chapter of the third chapter is the COM's apartment and COM thread model, although the space is short, but these content is important. Because ATL is a COM class library that supports multi-threaded models. In order to support multi-threaded, the price is very expensive, requiring every detail of the COM object to involve concocity, and ATL must take into account the size of the code, and It is necessary to take into account the running efficiency of the code, so ATL uses many techniques to ensure the effectiveness of its solution. After introducing the thread model, the author also tells some consideration points to implement the COM basic interface iUnknown. Afterwards, the level of the ATL object is given. If the reader does not understand the structure of the class in the ATL, then this level can let you know what kind of relationship with the class generated by Wizard and other classes, this picture can guide you Read the following two chapters. With these preparation knowledge, the author details the thread model support provided by ATL to object, limited to the space of this article, I can't tell these content in detail.

After telling the thread model, the author further introduces the base class CComobjectroTEX implementation of the CCOMOBJECTROOTEX to implement iUnknown. It is very simple to implement the reference count after the thread model, but the queryinterface member function is not the base class, it needs to be used. CComObjectroTex derived class is also the interface information provided by the class generated by Wizard. ATL provides an interface information of an object through an interface mapping table that implements a multi-interface support by multiple inheritance. The instantiation of the COM object is very different, because the class generated by Wizard is just an abstract class, so it cannot be directly instantiated, ie we can't generate an object with the New operator. The real object class should be CComObject, which implements all the methods of iUnknown, and provides a function for creating objects. If the object supports the aggregation model, then the final object class should be ccomaggobject. In order to unify the two cases to reduce the final amount, ATL provides the ccomPolyObject class as the final object class. The creation process of ATL is not complicated, but it provides a multiphase construction that allows us to add more control code during the creation process to get greater flexibility. The authors have been meticulous about this part, but also explains the meaning of the ATL_NO_VTBL macro novTBL compilation indicator. If a class declares NovTBL indicator, the compiler does not generate a virtual table in the formation class in the derived class ( vTable). The content of this chapter is the foundation of ATL. It is not difficult to read, but it must be clearly the level of ATL class, otherwise it is easy to fall into the complex syntax of ATL. Chapter 4 introduces the ATL support for the COM service, as a COM service, its main task is to manage object registration, provide a class factory for each object, as well as its own living management. Differentitions are required for components and processes in the process. The object implemented by the ATL is divided into objects that can be created by class, and cannot be created. Uncomfortable objects do not require support for class, often use other objects in the service. ATL implementation These features are primarily through object mapping tables and CCommodule classes. Object mapping table is a global table, including all object classes implemented by the current service program, each of the tables including the object's CLSID, registering the object information, the function of the creation of the work, the function of the class, etc. . With this information, the service program can manage each of the objects it supports. Turning back, in order to let the object mapping table manage these work, each object class also needs to provide the corresponding function or information, such as the registration function of the object, create a function, etc. ATL's registration function is very strong, in addition to the registration support of standard objects, it can extract the registration script file in the resource (Registry Script file), which is more flexible and powerful. For users, as long as the resource script is written, plus a macro statement. ATL is implemented in the CCOMCLASSFActory class in the CCOMCLASSFActory class, inherits the definition of a class factory creation class from CCOMCOCLASS. The implementation of the CCOMCLASSFActory class is not used to use the template parameters, but the embedded creation function, which is created by the function. This process is not complicated, and the book is very clear, and the book also introduces the approach of ATL to implement iClassFactory2. CCOMMODULE is the main line of the COM service. When we create an ATL project, Visual C will generate a ccommodule derived class for us, and define a global variable _Module, which is like using the CWINAPP application class in the MFC project.

Many member functions of the CCommodule class correspond to tasks it should complete, such as updating the operation of the registry, get the classwork object, the registration class object (for procedure servers), and so on. The content introduced in Chapter 4 is very useful for us to understand the overall thinking of the ATL project. Combined with the COM specification for all detail requirements in COM implementation, ATL gives an efficient and target implementation of small-size components. In conjunction with the content of the third chapter, the basic technical framework of the ATL implementation CoM is constituted. The fifth chapter describes the interface mapping table of ATL, in fact, this is a supplement to Chapter 3, but because ATL's interface mapping table is more flexible, and multi-interface support is important for COM objects. So the author uses the space to tell the interface mapping table alone. For multi-interface objects, COM has a strict specification to indicate that the client calls these interface member functions, especially iunknown :: queryinterface. In order to follow these specifications, and maintain certain flexibility, ATL uses the technology of interface mapping tables. The principle of the interface mapping table is very simple, which records the IID of each interface and the offset between the VTABLE and the THIS pointer of the interface, but the ATL interface mapping table is not as simple, it is function The form is encapsulated such a logical, allowing users to use more flexible interface query policies. ATL implements multi-interface support with multiple inheritance methods. If the method names and parameters of the two interfaces are coincident, there will be a problem, and a method of avoiding the name conflict is not complicated, but it is very effective. . This chapter introduces a technology called "interface coloring". It is actually very simple, but it is only constructed according to the virtual surface structure required by COM. It is the advantage that the two interfaces are identical but IID. But different interfaces. This also reflects the flexibility of COM interface implementation. In addition to supporting multiple inheritance methods, ATL has a very powerful interface support is support for dynamic interface, and the book is called "tear-off interface". Each dynamic interface class should be derived from CCOMTEAROFFOBJECTBASE. When the customer requests the interface to the object, the object class invokes the creation function specified in the interface mapping table to create the interface object. In addition to the structure of the interface mapping table, there is also the support of the aggregate interface, and the implementation form is very similar to the dynamic interface, and the ATL has a planned aggregation and blind polymerization. Blind aggregation, can be said that ATL is compared to aggregation support, but we must be cautious when we use, some of COM often implicit potential error probability, such as blind polymerization is such a feature . This chapter finally introduces some of the interface mapping tables, including the chain structure of the interface mapping table, refuses to support an interface, use the interface request to debug, the extension of the interface mapping table (for example, using the interface mapping table setting the back door, pass through the interface mapping table The rear door gets the THIS pointer of the object class; and an interface request based on an object instance). The content described in this chapter is very detailed, involving many subtle places in the COM specification, reading this part is not difficult, but requires readers to have associated COM background knowledge. The above four chapters are the cornerstone of the ATL, even if this part is independent, it can form a book "ATL in-depth". If the reader wants to rely on ATL to write COM components, then carefully read this part. If someone says that ATL uses C syntax very fancy, then they must refer to the content described in this section. Due to the complexity of the C template syntax itself, plus ATL uses "typedef" in many template classes, plus ATL also uses a macro structure similar to MFC, so read the origin code is very embarrassed.

Although the author tells this part of this part is very organized, I don't want to turn around before and after this chapter. Occasionally check the source code of the ATL. But once it understands the idea of ​​ATL, it is not exempt from its design. Part III ATL implementation COM: extended part of the ATL implementation COM extension section includes three chapters, respectively: Persistence in ATL (ATL's permanent support), Collectes and enumerators, Connection Points ( Connection point object). These three chapters are three big directions for the COM application, and it is also some common COM features that we are more common. If the reader wants to fully master the ATL, you should read this part. Chapter 6 introduces the support of the COM permanent mechanism. Relatively, this chapter is read more easily, as long as the reader is familiar with the COM permanent model. Since the complexity of the COM permanent model is primarily located in the client program, only several permanent interfaces related to the object, of course, these permanent interfaces are closely related to the logic of object itself. This chapter reviews the definition and implementation of IPersistPropertyBag, IPersistStream [init], iPersistStream [init], iPersistStorage permanent interface, then introduce the implementation of these permanent interfaces, focusing on the property map. The implementation of the permanent interface provided by the ATL automatically processes attributes in the properties map table, which provides LOAD and Save support. For permanent content that the attribute mapping table is not supported (such as examples of index properties raised in the book), we can overload processing in the appropriate place, and ATL allows us to overload this mechanism in multiple places. After introducing these common permanent interfaces, the author also introduces the IPersistMemory interface and detailed the importance of several permanent interface public member functions, as well as author supplement implementation methods. In this chapter, the author also gives a way to achieve a custom column (Marshaling) with permanent feature. If the reader is interested in the custom column, you can take a look at the last few pages. Introduction. Chapter 7 introduces the ATL implementation of the COM collection object and enumerator object. Before telling the set and enumerator object, the author first introduces the container and iterator (Iterator) in STL, which is the basic form of data organization and data access in STL, then the author takes a ratio, pointed out although STL cannot be used directly. COM, but COM provides a similar object organization and access mechanism, which is a COM collection object and an enumerator object. The collection object of the COM is the basis for constituting the COM object model. In order to be able to access the collection object when the client program is particularly VB (Visual Basic) or VBA, it can easily and effectively access set objects, COM sets the interface specifications of the collection object and The interface specification of the object. ATL implements these specifications, and in the ATL, there is also a variety of ways to manage these member data or members objects. The aggregation object of the ATL is relatively simple, and as long as the COM specification, add the attributes unique to the collection object: count, item, _newenum. _Newenum properties linked a collection object and enumeration object. In the ATL, the enumeration number group is ccomenum, which manages its member data in the form of an array. It is worth mentioning that the ATL is in order to facilitate copy operation of the data, specifically abstract abstract For the class of "copy policies", the member copy operation is implemented by the static member function of this class.

ATL truly realizes the classes of enumeration interfaces as ccomenumImpl. It is the base class of ccomenum. The implementation of CCOMENUMPL is not complex. The only thing that is worth noting is that the way CCOMENUMPL saves data, which can be either a snapshot, or reference objects. data. With these foundations, plus the ATL object class introduced by the previous section, which is very easy to implement enumeration objects. The author describes the entire process in an example in books, and finally passes the _newenum attribute of the number set object. It is associated with the number of enumeration objects. The second half of the seventh chapter describes the STL as a data organization method to implement the COM collection object and enumeration object. If the reader is not very familiar with STL, this part of the content can be jumped and has no translation. The main difference between the set object and the enumeration object and the front method is to achieve the internal implementation details of the object, and the basic ideas and models are still consistent. The enumerator corresponding to CCOMENUM is CCOMENUMONSTL, and the enumeration interface corresponding to CCOMENUMPL implementation class is Ienumonstlimpl, which can be very flexible, and the books are illustrated in the book. If an enumeration object is implemented with STL, the collection class also needs to provide the corresponding support, and the better approach is to implement the collection class with STL. The author introduces IcollectionOnstlimpl, which works with CCOMENUMONSTL to achieve collection objects and enumeration objects. In this chapter, the author introduces how to encapsulate ATL's data type (which is some classes described in Chapter Chapter 2) into STL's containers, which may be very useful for those STL fans, and it is also very interesting. At the end of this chapter, the author constructs a simple object model example with the previous content, allowing the reader to know how to apply the collection object and enumeration object to the object model, and play a global guidance. Chapter 8 describes the ATL implementation of the connectable object, first review the COM's connectionful object mechanism, pointing out that the ATL uses two full-end functions atladvise and ATLunadvise to establish a source between the source object and the receiver object or cancellation between the two. connection. Connectable object is a two-way communication mechanism of COM, which does not apply complex technologies, actually a reverse application of COM. The author then begins with an example to tell the entire process of the ATL to implement the connectable object (divided into seven steps), including how to implement the IConnectionPointContainer interface, how to implement each connection point object, how to increase the connection point mapping table, and how to write an event excitation function or Let Visual C integrated environments generate event excitation functions. After introducing the implementation process of the source object, the author also introduces the process of the client to implement the event receiver object. Relatively, this process involves more details, because ATL's template IdispatchImp only supports dual interface. DISPINTERFACE is not supported, an outgoing interface of the source object is often DISPINTERFACE, so the receiver object is to implement an event interface through other ways. ATL provides two template class IDispeventImpl and iDispeventsImpleImpl for the implementation of the receiver object, and IdispeventIMPL is the easiest implementation method, which is the easiest implementation of the exit type information provided by the type library, and IdispeventSIMPLEIMPL does not need the support of the type library. It is the highest efficiency method. Both of these methods require an event receiver mapping table (Event Sink Map), and programmers can submit specific event functions and corresponding DISPID information to a customer class through ATL. Cooperate with the example of the source object given, the author also provides an example program for the client receiver object during the explanation.

After introducing the usage of connected objects in ATL, the author continues to explain the implementation details of this mechanism, including the following points:

The source object implements the principle of the IconnectionPointContainer interface, including how to manipulate the connection point object enumerator, how to use the connection point mapping table. Connection point object Implement class iconnectionPointImpl. Includes how to manage multiple connections, how to manipulate the connection enumerator object, how to implement multiple connection points on one source object. Multiple classes involved in the event receiver object. Including _idispevent, _idispeventlocator, idispeventsimpleImpl, and the basic principle of the event receiver mapping table is also discussed. The content introduced in this chapter is relatively simple. If the previous part of the foundation is better, these contents can be read easily. Although the content is relatively simple, it is very helpful for the connectionful object mechanism of our skilled application ATL, because in actual work, fully manually implement the connectable object mechanism is very cumbersome, even if the ATL's Wizard has provided support, Many manual work should be required to make the connectable objects and receiver objects really work. So this part is very practical. The above three chapters are COM extensions, but we often encounter these content in actual work, especially the permanent feature of COM, which has a very broad application background, such as the ActiveX you want to talk about. Control is supported by these two technologies, while the collection objects and enumerator objects are object organizations that the VBA program is very dependent. Part IV ATL's support for windows and ActiveX control We know that COM is a platform-independent component specification, but COM applications are almost all related to the Windows platform, which is determined by the historical background of COM. The content of the fourth part of this book is how ATL implements features related to user interface, especially how to encapsulate windows, how to support ActiveX control. In the two sets of libraries provided by Visual C , the MFC focuses on encapsulation of interface features on the Windows platform, including a variety of windows, dialogs, a large number of control classes, etc., while ATL focuses on the package of COM. However, as the MFC also provides COM support, ATL also provides support for user interface, which is the ATL window package to be discussed in Chapter 5. The foundation of the package is still Win32 API. Chapter 9 The content discussed does not involve COM, which is completely many details related to the window on the Windows platform. The author springs from the basic model of the Windows window application, telling the three major elements of the window: window class (WNDCLASSEX structure), Window Handle (HWND) and Window Process (WNDPROC), which is also a few points of the package window. ATL's window class hierarchy is much simpler than MFC, with the main classes of CWindow, CWindowImpl, CDialogImpl, and CContainedWindow, then the author introduces these classes one by one. The CWindow class is very simple, it is just a package of the window handle HWnd, almost all the API functions related to the window have a corresponding CWindow member function. These member functions are just a simple package. CWindowIMPL is a key class in the ATL window class. On the one hand, inherits from CWindow, it solves two key issues of the window: the registration and window message processing of the window class. The registration of the window class is the necessary condition for creating such a window. The CWindowIMPL class encapsulates this process, and the programmer can complete these necessary tasks only need to use simple macros. The CWindowIMPL class implementation window process uses a little skill, because the window process is identified as a window object with hwnd, and CWindowIMPL is a THIS pointer as an object identifier, so it is a key to establish a correspondence between the HWND and THIS pointers.

CWINDOWIMPL's base class CWINDOWIMPLBASET is established in the first calling process in the first call, which is built in a set of machine instructions established during the running process in the running process in the first call. Each window object has a Thunk object. The THUNK task is to replace the hwnd in the stack before calling the Static member function of the CWindowImpl class. This process has been detailed in the book. Readers who are interested in the bottom layer of the ATL can take a look at this part of the content introduction, very interesting. The mapping of the HWND to the THIS pointer is just a small step. The fundamental goal of the window process is to process the message of the window. The ATL's message processing mechanism is very powerful. First it takes advantage of a set of macros to construct the ProcessWindowMessage member function, once these The macro shows, is actually a standard Switch statement, and a large pile of IF statements under each case. This program structure is significantly different from the MFC message mapping table, and the MFC message mapping table handles each message by checking the table. ATL's message support is very flexible, we can specify a message processing function by the message code, or you can specify a process function according to the scope value of the message code, and provide support for command messages and notification messages. More powerful is that the ATL's message table can constitute a chain, which is linked to the message table of the derived class and base class. If there are multiple base classes, all of these message tables can be chained. And in each class, the message processing item in the message table can be packet, and some are used to derive class, some for itself, providing many opportunities for derived classes. Understand CWindowImpl, then understanding CDialogIMPL, which is easy, the same Thunk technology, the same message chain technology, which is different from the underlying Win32 API has different processing, and the dialog is divided into a mode dialog and a modeless dialog. If the reader has written the dialog box class with the MFC, it must be impressed with the DDX / DDV function. These function calls generated by the class wizard completed data exchange and data validity between the dialog member variables and dialogs. Judging Unfortunately, ATL did not provide such a function, we had to solve itself, but it is not difficult to do it, and you can achieve more flexible. We know that the MFC encapsulates a lot of control classes, and there is not so much control class in the ATL window tree. In fact, all of these control packages are given in the ATLCON example, just without formal documents. Moreover, these classes are very simple, the source code itself is the best document, we can make full use of these resources. This chapter finally introduces CContainedWindow, it is special, it is handed over to the parent window after receiving the message, and the parent window can create such a sub-window directly, or the window object that has been created. Use the "subclass" technology to intercept the window process. The content of Chapter 9 is completely independent of COM, but it is a different part of the ATL library, especially for ATL projects with user interfaces. Chapter 10 tells how to use ATL to establish ActiveX control (most Chinese data call "ActiveX Control" as an ActiveX control). ActiveX Control is a large integration of COM technology, and it is also a big integration of OLE technology. If it is purely from a technical point of view, there is almost no book to fully describe the technologies of ActiveX control. ATL is more comprehensive for ActiveX control, and its application is very flexible, and programmers can select some part.

Chapter 10 The author first reviews the functions of ActiveX control, then starts from an example Bullseye's functional analysis, using ATL Wizard to create an initial ActiveX control framework, and explain one by one on the options involved in the creation process. With the initial control code, the next task is to improve the functionality of Bullseye-by-item, as follows:

The first is to increase the attributes and methods of Bullseye control, because ActiveX control is an ultra-array of automation technologies, and the package container needs to communicate with the IDispatch interface or dual interface, so the control is based, attribute, and method. Both: stocks (stock) and custom (CUSTOM). ATL supports the inventory properties class as CSTOCKPROPIMPL, which inherits from the IdispatchImpl class. Custom attributes and methods can be added through "Add Method" and "Add Property" provided by the VC integration environment, which automatically updates the IDL interface definition file and the corresponding source code .h file. Join Event Support. First add an event definition of an interface in the IDL file, then join the connection point support and the support of the IconnectionPointContainer interface. ActiveX Control In addition to supporting custom outlets, it also supports the iPropertyNotifyInsink interface as an interface, which is specifically used to provide attribute change notifications to the package container program. ATL's class iPropertynNotifySinkCP implements the corresponding connection point object. The basic mechanism to achieve connection point is described as described in the above, just ATL provides more convenience to ActiveX control. As the content related to the connection point, an ActiveX control should also support the iProvideClassInfo2 interface, the corresponding ATL class is iProvideClassInfo2Impl. As an ActiveX control, the necessary graphic information is drawn in the window is one of its tasks. ATL only provides a drawing framework, and the specific drawing task is completed by derived classes. For our writing ATL control, it is an OnDRAW function. Permanent properties. This is the integrated application of the seventh chapter, directly using the permanent interface provided by ATL, and the controlled property mapping table. A customer-friendly ActiveX control should implement iQuickActivate interface, ATL thinks very thoughtful, it implements this interface, handle the relevant logic to the IQUickActivate_quickActivate member of the control class. Component category. The category feature of the Category mapping table using ATL is easy to implement. The function of the property classification. ATL does not provide support, but we can easily implement the IcategorizeProperties interface. Browsing the properties. This is the task of interface IperPropertyBrowsing, and ATL provides interface implementation IperPropertyBrowSingImpl, and we can use the relevant member function. ActiveX control keyboard processing. This is the collaboration foundation between ActiveX control and bag containers, and we only need to reload the necessary functions according to the specification of ActiveX control. The content coverage of this chapter is relatively wide, the author demonstrates the ATL implementation of the full-featured ActiveX control through the Bullseye example program. There are many places to use the ATL class or the corresponding various supports described earlier. This example is highly inspired by our own ActiveX control. The last chapter describes the case of ActiveX is used by the package container program. The author first introduces the cooperative overview between ActiveX control and the bag containers, and then describes the basic technology of the ATL to achieve an inclusion. The CAXHostWindow class is an ATL to achieve internal base classes of tolerance control. The author from the ActiveX control creation process explains how CaxHostWindow class participates between the collaboration between the package container window and the control, we know that the package container manages ActiveX control by controlling the site object, here the CAXHostWindow object is equivalent to the controlled site object, it It is not explicitly created by the client program, but is implicitly created during the process of creating a control, which involves many collaborative details. The author spent a lot of space to tell this process, once this process is clear, then other details are very simple.

The process of joining the event control is simple, as described in Chapter 8, using the IDispeventimpl class, add the receiver event mapping table, and then establish a connection between the receiver and the control when appropriate. Similarly, we can implement the iPropertyNotifyInsink interface on the package container and establish a connection between the control to handle the control of the attribute change notification. The processing of the attribute page is also a task for the package container program, but the process is relatively simple, just call the OLE function OlecreatePropertyFrame. The permanent process of control is not complicated, and the SAVE and LOAD members that control the permanent interface can be called in the save and recovery operations of the package container. In addition to inclusive ActiveX control in a general window, the dialog box is also a typical situation as a package container window. For the client program, it is easier to use ActiveX control in the dialog. In the programming phase, the integrated environment is often able to do more things for us, such as controlled initial state processing, controlled event processing, etc. But still some work requires us to handle it in the later period, such as establishing the connection between the receiver object and the control, writing event functions, etc. In practical applications, new controls with ActiveX control or Windows standard control constructs are a useful technology, which is composite control, and ATL also supports composite control, which combines the functionality of the dialog box and ActiveX control. When constructing composite control, we can specify a dialog template to introduce the interface template completed by the design phase into the composite control, which is a very simple construction of the interface unit. Another way to construct the interface unit of another function is HTML control, which uses web browser control to encapsulate the HTML page into a new ActiveX control directly. Since it uses the HTML page as the interface content, it is very flexible when used, we can embed the script in the HTML page, you can use a variety of fonts to access the object model of the HTML document. The content of this chapter is also relatively wide, but it combines the ActiveX control introduced by the previous chapter. And through these contents, we can broaden the field of view to make ActiveX control applications more flexible, introducing the web into our desktop, or introducing the desktop's functionality to the web. The content of these two chapters is relatively independent, which constitutes the body develops and uses ACTIVEX control with ATL. If the reader pays attention to MSJ Magazine, you can find a serial load on these content in 1999, and the name of the article is: "Write ActiveX Controls Using Custom Interfaces Provided by ATL 3.0". The eleventh chapter is the last chapter of the book. We follow the author from the basic wizard development. After deeply shallow analysis, we finally reached a stop, it can be easily. But this is not equal to our learning ATL's mission has been completed, and there are still many contents of ATL to be tapped. Conclusion For the development of COM applications, ATL is undoubtedly the preferred tool. Compared with MFC, the size of the ATL is not big, but from the above introduction We can see that ATL involves all as comeback. In fact, the content of ATL is much more, such as OLE DB support, MTS support, etc. Despite this, if we have the content of this book, then learn these extensions will be easy. More, combined with the basic means of achieving COM in combination with these application technology background knowledge, we can easily grasp these development technologies. But if we want to master even the ATL, then this is just a beginning, there is a long way to go in front.