MFC DLL Wizard (i)

Although something that can be implemented with a DLL can be implemented with COM, the DLL has many advantages, and it is easier to create. This article discusses how to use MFC to create different types of DLLs, and how to use them.

One, different types of DLLs

You can use MFC to generate two types of DLL:MFC extension DLLs and regular DLLs. General DLLs can be divided into dynamic and static connections. Visual C + + can also generate WIN32 DLLs, but not the main objects discussed here.

1, MFC Extension DLL

Each DLL has some type of interface: variables, pointers, functions, classes accessed by client programs. Their role is to have the client program use the DLL,MFC extension DLL to have C + + interfaces. That is, it can export C + + classes to clients. The exported function can use the C++/MFC data type as a parameter or return value, and when exporting a class, the client can create the class object or derive the class. Also, DLLs and MFC can be used in DLLs.
The MFC class library used by Visual C + + is also a DLL in which the MFC extension DLL dynamically connects to the MFC code base, and the client program must also dynamically connect to the MFC code base DLL. (Here are two DLLs, one is our own DLL, a DLL to install MFC class libraries) Now there are multiple versions of the MFC code Library's DLLs, and both client and extension DLLs must use the same version of the MFC code DLL. So in order for MFC to extend DLLs to work well, both the extension DLL and the client must dynamically connect to the MFC code library DLL. This DLL must be on the computer where the client program is running.

2. General DLL

One problem with using MFC to extend DLLs is that DLLs work only with MFC clients, and if you need a more extensive DLL, it's best to use a regular DLL because it's not limited by MFC. A generic DLL also has its drawbacks: it cannot send pointers or references to MFC derived classes and objects with the client program. The bottom line is that the interfaces of regular DLLs and client programs cannot use MFC, but MFC can be used internally by DLLs and client programs.
When you use a DLL for an MFC code base inside a regular DLL, you can be a dynamic connection/static connection. If it is a dynamic connection, that is, the MFC code required by a regular DLL is not built into a DLL, which is somewhat similar to an extension DLL, you must have an MFC code base DLL on the computer where the DLL is running. If it is a static connection, the generic DLL already contains the required MFC code, so the DLL will be larger, but it can run correctly on a computer that does not have an MFC code library DLL.

Ii. Establishment of a DLL

With the wizard features provided by Visual C + +, it is easy to create a DLL that does not accomplish any of the substantive tasks, and here's a little more about how the main task is to add functionality to the DLL and use this DLL in the client program

1. Export class

After you have established the framework with the wizard, you can add the. cpp. h files that need to export the class to the DLL, or use the wizard to create C + + Herder file/c++ Source file. In order to be able to export this class, add "_declspec (dllexport)" To the class declaration, such as:

class _declspec(dllexport) CMyClass
{
...//声明
}
如果创建的MFC扩展DLL，可以使用宏：AFX_EXT_CLASS:
class AFX_EXT_CLASS CMyClass
{
...//声明
}

This method of exporting the class is the simplest and can also be exported with a. def file, which is not detailed here.

2. Export variables, constants, objects

Many times you don't need to export a class, you can have your DLL export a variable, a constant, an object, and you just 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);

You must use the keyword extern to export a constant, or a connection error will occur.

Note: If the client recognizes this class and has its own header file, only one class object can be exported. If you create a class in a DLL, the client does not recognize the class without using a header file.
When you export an object or variable, each client program that loads the DLL has its own copy. That is, if two programs are using the same DLL, the modifications made by one application will not affect the other application.
When we export, we can only export global variables or objects in the DLL, not local variables and objects, because they do not exist because they are too scoped, so the DLL does not work properly. Such as:

MyFunction()
{
_declspec(dllexport) int MyInt;
_declspec(dllexport) CMyClass object;
}