Let's review the process of using the dialog box in Win32 DLL. In DLL, we define two dialog resources: IDD_DLG_SHOW and IDD_ABOUTBOX, and export the function showdlg. The non-modular dialog IDD_DLG_SHOW is created using the CREATEDIALOG function in the function showdlg, and specifies the callback function DLGProc of the dialog. WM_INITDIALOG, WM_COMMAND, and WM_CLOSE messages are processed in DLGProc to respond to the action made by the user on the dialog. When processing the button action, create an IDD_ABOUTBOX using the Dialogbox function, specify its callback function to AboutProc, and process its corresponding message in the ABOUTPROC. In EXE, we use implicit link to call DLL and use the showdlg function exported in the DLL to call dialogs in the DLL. Using dialog box in Win32 DLL is as simple, let's take a look at how to use the dialog in the MFC DLL. 2. The MFC DLL uses the dialog box in the MFC DLL unlike the Win32 DLL as simple as Win32 DLL, mainly because there is a problem with a module status in the MFC program, that is, resource duplication issues. (The term module here refers to a DLL (or a set of DLLs) of a DLL (or a set of DLL) that does not depend on the rest of the application but use the MFC run library. The MFC DLL we created is A typical example of this module.) In each module (EXE or DLL), there is a global state data, and the MFC relies on this global state data to distinguish between different modules to perform the correct operation. This data includes: Windows universal handle (for loading resources), pointing to the pointer of the application current CWINAPP and CWINTHREAD object, OLE module reference count, and various mappings that maintain the Windows object handle and the corresponding MFC object instance Wait. However, when the application uses multiple modules, the status data of each module is not the scope of the application. Instead, each module has a private copy of the MFC status data. This global state data is called the MFC module state. The state data of the module is included in the structure and can always be used by a pointer to the structure. When the code enters a module when executed, only the status of this module is "current" or "valid" state, the MFC can correct this module and perform the correct operation. For example, the MFC application can load a string from the resource file using the following code: cstring str.loadstring; use this code very convenient, but it hides the fact that Ids_mystring in this program may not be unique Identifier. A program can load multiple DLLs, some DLLs may also define a resource with the IDS_MYSTRING identifier. How do MFC know which resource should I load? The MFC uses the current module status to find the resource handle. If the current module is not the correct module we want to use, it will generate incorrect calls or errors. According to the Link method of the MFC library, a MFC DLL has two ways to use the MFC library: static links to the MFC DLL and dynamic links to the MFC DLL. Below we will introduce how to switch the current module status in the correct way to use resources in the MFC DLL in accordance with these two types of MFC DLL. 1. Static link to the MFC's DLL static link to the MFC rule DLL and the MFC library static link, then the MFC library cannot be shared, so the MFC always uses the module status of the DLL it linked. This does not have problems with the status of the management module.
However, the disadvantage of using this method is that the DLL program will become large, and repeated code will be left in the program. The example given below verifies this. This example can be done by following these steps: 1) In the VC menu, File-> New has newly created a project named Dllstatic's MFC AppWizard, the next step Select Regular DLL with MFC STATILLLINKED. 2) Add a dialog resource in the project, which ID is: IDD_ABOUTBOX. And change the value of IDD_aboutbox to 100 among resource.h. 3) Define the following functions in dllstatic.cpp: void showdlg () {cdialog DLG (IDD_AboutBox); DLG.Domodal ();} 4) Add a line in the exports statement in the dllstatic.def file: showdlg to export the showdlg function . 5) Compile DllStatic.dll and DllStatic.lib. Continue to use the USE project in the previous section, copy the previously generated dllstatic.dll and dllstatic.lib to the project's debug directory, and put the extern "c" __declspec (dllexport) void showdlg (); #pragma comment (LIB, "Debug / UseDLG") These two rows are changed to: void showdlg (); #pragma comment (lib, "debug / dllstatic") Compile and run use.exe. Click the button to see the modal dialog box in DllStatic pops up. In this case, you can notice that the About dialog resource defined in the DLL is identical to the About dialog resource ID defined in the exe, but when we click on the button above Use.exe, the modality of the DLL is Dialog. Note When using a static link to the rule DLL of the MFC, there is no problem with the status of the management module. 2. Dynamic links to the MFC's DLL to see an example before discussing the status of DLLs of dynamic links to the MFC. This example can be completed by following: 1) In the VC menu, File-> New has newly created an engineering for MFC AppWizard named Dllshared, the next step Select Regular DLL Using Shared MFC DLL. 2) Add a dialog resource in the project, which ID is: IDD_ABOUTBOX. And change the value of IDD_aboutbox to 100.3 in resource.h) Define the following functions in dllshared.cpp: void showdlg () {cdialog DLG (IDD_aboutbox); dlg.domodal ();} 4) in dllshared.def Add a line in the exports statement in the file: showdlg to export the ShowDLG function. 5) Compilation to generate dllshared.dll and dllshared.lib.
