Although things that can be implemented with DLL can be implemented with COM, the advantages of DLL are really a lot, it is easier to create. This article will discuss how to use MFC to create different types of DLLs, and how to use them. 1. Different types of DLLs use MFC to generate two types of DLL: MFC extensions DLL and regular DLL. Conventional DLLs can be divided into dynamic connections and static connections. Visual C can also generate Win32 DLL, but not the main objects discussed here. 1, MFC Extended DLL Each DLL has some type of interface: variables, pointers, functions, classes accessible. Their role is to let the client program use the DLL, the MFC extension DLL can have a C interface. That is, it can export the C class to the client. The exported function can use the C / MFC data type to make parameters or return values, export a class, when the client can create a class object or derived this class. At the same time, DLL and MFC can also be used in DLL. The MFC class library used by Visual C is also saved in a DLL, the MFC extension DLL dynamically connects to the MFC code library, and the client must also dynamically connect to the DLL of the MFC code base. (Talking about two DLLs, one is our own written DLL, a DLL of a MFC class library) Now there are multiple versions of the MFC code library, and the client and extension DLL must use the same version of the MFC code. DLL. So in order to make the MFC extended DLL work well, extended DLL and client programs must dynamically connect to the MFC code library DLL. And this DLL must be on the computer running on the client program. 2. A question of conventional DLL uses the MFC extended DLL is that the DLL can only work with the MFC client, and if you need a broader DLL, it is best to use conventional DLL because it is not subject to some of the MFC. Conventional DLL also has a disadvantage: it cannot send pointers or magpc derived classes and object references. One sentence is that the connections of regular DLLs and client programs cannot be used, but MFCs can be used inside the DLL and the client program. When the DLL of the MFC code base is used inside the conventional DLL, it can be dynamic connection / static connection. If it is a dynamic connection, that is, the MFC code required by the regular DLL does not build into the DLL. This situation is a bit and extended DLL, and the MFC code library must be the DLL of the MFC code base on the computer. If it is a static connection, the regular DLL already contains the required MFC code so that the volume of the DLL will be relatively large, but it can operate normally on a computer without the MFC code library DLL.
Second, establishing a DLL using the wizard feature provided by Visual C can easily establish a DLL that does not complete any substantive tasks. Here, there is not much tailorful, how the main task is to add functions to the DLL, and use this DLL1 in the client program. Once you have exported the class wizard, you can add a .cpp .h file to the DLL that you need to export classes, or create C Herder File / C Source File with the wizard. In order to export this class, add "_declspec (dllexport) when class declaration, such as Class_Declspec (DLLEXPORT) CMYCLASS {... // declaration} If the created MFC extension DLL, you can use macro: AFX_EXT_CLASS: Class AFX_EXT_CLASS CMYCLASS {... // Declaration} This method of exporting classes is the easiest, or it can be used. DEF file export, here is not detailed here. 2, export variables, constants, and objects do not need to export a class, allow DLL to export a variable, constant, object, export them only need to make a simple declaration: _Declspec (DLLEXPORT) Int Myint; _declspec (dllexport) Extern const colorRef MyColor = RGB (0,0,0); _declspec (dllexport) CRECT RECT (10, 10, 20, 20); Must use the keyword extern when a constant is to be exported, otherwise a connection error will occur. Note: If the customer program identifies this class and has its own header file, you can only export a class object. If you create a class in the DLL, the client cannot identify this class without using the header file. When you export an object or variable, each client that loads the DLL has a copy of your own copy. That is, if the two programs use the same DLL, the modification of an application does not affect another application. We can only export global variables or objects in the DLL during export, and cannot export local variables and objects, because they don't exist in the role domain, so the DLL does not work properly. Such as: myfunction () {_declspec (DLLEXPORT) INT Myint; _Declspec (DLLEXPORT) CMYCLASS Object;} 3, export function export function and export variable / object Similar to function prototypes: _Declspec (DLLEXPORT) INT myfunction (int); if it is a regular DLL, it will use the program written with C, declare the following: Extern "c" _declspec (dllexport) int myfunction (int); implement: Extern "C" _Declspec (DLLEXPort Int myfunction (int x) {... // Operation} If created is a normal DLL that is dynamically connected to the MFC Code Base DLL, you must insert AFX_Manage_State as the first line of the export function, so defined as follows: Extern "C" _Declspec (DLLEXPORT) INT MyFunction (AFX_MANAGE_STATE ()); ... // Operation} Sometimes, in order to be safe, plus any problems, nothing, just in static This macro is invalid when it is connected.
