In-depth exploration of MFC and ATL, MS COM development framework
By Tomhornson (@) Hotmail.com
-------------------------------------------------- ----------------
Article index:
First, outlined and to be desired
Second, MFC, ATL COM support principle overview
Third, macroblock
☆ ☆ MFC articles
Part1 ---- The origin of the interface foundation structure
Part2 ---- In-depth ccmdtarget to see the implementation of the three elements of COM
Part3 -------- Class factory
Part4 ------- Automation Support
Part 5 ------- Component Terrace: Several core functions
☆ ☆ ATL
Part1 ---- Several core template class introduction
Part2 ---- Template Putting Sky: The origin of the interface
Part3 ------- Automation Support
Part4 ------ In-depth core template class
Part 5 ------- Component Terrace: Several core functions
-------------------------------------------------- -------------------------
CoM is a difficulty. The reason is that its own design is in full care of a lot of detail, nine songs 18 bends, confusing.
However, MS is usually confused, and many people are confused, they have not been thinking about it for a long time. So MFC, ATL uses a macro to provide
The support of COM is even more .... Below we will explore the MFC, ATL is open on the process of components in the process.
What is the foundation support of the hair ...
First, outlined and to be desired
First give you a description of the COM structure: There is a large number of component classes in components (DLL, EXE, OCX, etc.).
(COCLASS), each component is maintained for N to maintain N, and the method is maintained behind the interface. Naturally there is a class
(ClassFactory), the class is a parallel class of the component class.
Yes, then how the MFC, how does ATL do the above structure?
For MFC, we need to analyze the exclusions:
There is a macro in the component class .h and .cpp files:
1. Declare_DyncReate (CSAM)
Implement_dyncreate (CSAM, CCMDTARGET) [. CPP]
Brief description: Support RTTI and dynamically create class object capabilities.
About this, will not explain in detail below.
For more details, please refer to
"In-depth, MFC", the same principle
2. Declare_Message_map ()
Begin_MESSAGE_MAP (CSAM, CCMDTARGET) [CPP]
END_MESSAGE_MAP ()
Brief description: Maintain the message processing system, because the MFC is still
Take the CWINAPP object as the core.
For this, will not be detailed below.
For more information, refer to "Deep Shallow MFC".
3.Declare_olecreate (CSAM)
Implement_olecreate (CSAM, "MFCcom.sam",
0x43d242f9, 0x4f7e, 0x4cbb, 0xae, 0xDa, 0x77, 0x8d, 0xa1, 0x16, 0xD0, 0xD9)
Brief description: Create a class factory object and associate the class and component classes.
Provide guarantees for creating class instances via CLSID.
4.Declare_dispatch_map ()
Begin_Dispatch_map (csam, ccmdtarget) [. CPP]
END_DISPATCH_MAP ()
Brief description: Support automation distribution, in fact,
Here is the true intention of MFC support for COM.
Because the MFC default derived interface is DISPINTERFACE
(Pure DISPATCH interface), details will be described below.
5.Declare_interface_map ()
Begin_INTERFACE_MAP (CSAM, CCMDTARGET) [. CPP]
Interface_part (csam, IID_ICOM, DISPATCH) END_INTERFACE_MAP ()
Brief description: Create an interface mapping table, the method here is visible in the Framework of the MS.
Although the implementation of possible details is different.
In the DLL master file: [xxx.cpp]
1.AFX_Manage_State (AfxgetStaticModuleState ())
Brief description: Here is the status management of the module.
Very important, it maintains the procedure
A lot of information, we will discuss the class tables.
2. ColeObjectFactory :: registerall ()
Brief description: Register all types of works when DLL is initialized.
3. AFXDLGETCLASSOBJECT (RCLSID, RIID, PPV);
Brief Description: Get a class pointer according to RCLSID.
Several important functions:
EnableAutomation ()
Brief description: existing in the constructor of each component class
Make the XDiaPatch included in ccmdtarget first get
Another VTABLE that implements objects that implement IDispatch,
This makes the interface class built by Programmers become true
Advantages.
Here is a bit complicated, detailed below.
2. AFXOLELOCKAPP ()
Brief description: existing in the constructor of each component class
Natural components must be Creatable By ID
Come explicitly.
When you create a component object, lock the app and enter the critical area.
3. AfxoleunlockApp ()
Brief description: Existing in papers of each component
Natural components must be Creatable By ID,
Come explicitly.
Exit the critical area.
Whether OLE Automation creates all objects destroyed,
The application is terminated and is called in the destructor.
4. ccmdtarget :: onfinalrelease ()
After the final reference to the component class object is released, the end of the end.
The Hongluo listed for the ATL we need to analyze is as follows:
Macro in the component class .h file:
In .h file:
1. Declare_registry_resourceId (idR_SIM)
Brief description: Support for registry script registration components, scripts
One of the resources in ATL as a resource.
2.Declare_protect_final_construct ()
Brief description: Prevent component class objects from being deleted.
3. Begin_COM_MAP (CSIM)
COM_ITERFACE_ENTRY (ISIM)
COM_ITERFACE_ENTRY (Idispatch)
END_COM_MAP ()
Brief Description: Generate a COM mapping table, which is the same as the MFC interface mapping table.
In the .cpp file: [xxx.cpp]
5. Begin_Object_map (ObjectMap)
Object_ENTRY (CLSID_SIM, CSIM)
END_OBJECT_MAP ()
Brief description: Generate a component class table, save a lot of information, including
CLSID, components class, update the pointer of the registered member function,
Get a pointer to the member function, create a pointer to the component class instance member function.
It is also a key here.
We found that the above MFC and ATL macro are different. Yes, in fact, the techniques they achieve are also very different.
Second, MFC, ATL COM support principle overview
First we must clear: MFC, ATL supports the child's technique of COM.
The MFC is through nested, and ATL is inherited.
MFC Support Method Overview: In a general nested class solution, a pointer is required in nested objects.
The pointer to the parcel object can be transferred between the interface (actually a nested object), and implements a wrapping class.
The communication of itself. However, due to programmers, it does not need to handle itself in QueryInterface.
The interface pointer points to the correct address. In fact, the ATL technique does not need. So the MFC is implemented in the specific implementation of the MS: built offset table. Record IID and interface vtable and parcel objectively
The offset between the site. This way, when obtaining the address of the component class, you can get the address of the interface, thus
Calling method. Nature, there is still a problem you can't feel: do not take special means
The interface pointer returned to the parcel will be a problem, but the solution on this issue is:
Early, the Nested AddRef, Release, QueryInterface, transfer to the call of the parcel class.
Is this still afraid of going back? This is achieved in xdispatch.
There is no way MS is just like Data-Driven, and in its product, this technique does play the fire pure.
I experieved that it is indeed more than it in nesting classes.
The method is not good.
The origin of all means here is a characteristic of solving the class nested.
It is worth mentioning that the technique used here is the style of aggregation of components. You will take this feeling.
Thorough understanding of aggregation and here for nesting ...
ATL support method Overview: ATL's support method, may be close to your thinking. Component class inherits from any interface,
This allows the user to implement the virtual feature of the interface in C , naturally with the MFC, the interface must be shared
A set of addRef, release, queryinterface implementation. This is also guaranteed by the virtual machine system of C .
