I often use the interface class with third-party rewriting during the development process. After adding these classes, the entire engineering structure is more complicated, and the maintenance has increased difficulty, so I always wanted to encapsulate these third-party classes, which generates a static connection library, so There are many files in the project, and the entire engineering structure has become more clear. Some information is found online, and the source code of CJLibrary has finally realized their own purpose. The following is an example implementation process. For example, the inheritance class CxListCtrl encapsulated induction of CListCtrl; creating a library, create an empty "Win32 Static Library" project; second step, add file, select menu "Project" -> "Add to Project "->" files ", select CXListCtrl.cpp and cxlistCtrl.h file, add to the project, modify the class definition of CXListCtrl.h, modify Class CXListCtrl: public clistctrl to class AFX_CLASS_EXPORT CXListCtrl: public clistctrl; third step, then Create a new header file stdafx.h, add the MFC header file required by the CXListCtrl class into stdafx.h, this example stdafx.h file content is as follows, #define vc_extralean // Exclude Rarely-useed stuff from Windows Headers
#include
#ifndef _AFX_NO_OLE_SUPPORT #include
#pragma Warning (Disable: 4251) // Remove 4251 Warning #pragma Warning (Disable: 4275) // Remove 4275 Warning Step 4, set Win32 Release Engineering Parameters, "Project" -> "Setting" -> "General "->" Microsoft Foundation Classes "Select" Not USE MFC ", in" Setting "->" C / C "->" Preprocessor Definitions "fill in" NDebug, Win32, _Windows "fifth step fifth step, compile generation of Release version The "lib" file call process first step first, create a Dialog project; step 2, add the cxlistctrl.h header to the project, then you can write the code using the CXListCtrl class; third step, generate The lib file is copied into the Dialog Engineering Directory, modify the stdafx.h file, join the #pragma comment (lib, "xxx.lib") // after the file is added in the fourth step in the fourth step, compile, compile using Win32 Release By, call success! Below is an article posted related articles: Source: http: //www.codeproject.com/dll/dllexport.aspExporting C classes from extension DLLs and importing those classes into applications can be a little confusing at times This article discusses one of. many ways to simplify this. Also discussed is a technique to ensure that your DLL's .LIB file is automatically linked into any application (or other DLL) using your DLL, avoiding the need to alter your project link settings.
When Building An Extension DLL, You Want The Compiler / Linker To Export SELECTED C Classes, Buthen Building your application you want to import those classes.
Traditionally, this has been done by using the AFX_CLASS_EXPORT and AFX_CLASS_IMPORT defines (defined in afxv_dll.h). Swapping these #defines in and out depending on whether you're building the DLL itself or building an application (or another DLL) which uses your Exported classes.
IF WE LOOK ATHOW AFX_CLASS_EXPORT and AFX_CLASS_IMPORT Are Defined in Afxv_dll.h We See The Following. # Define AFX_CLASS_EXPORT __DECLSPEC (DLLEXPORT)
#define AFX_CLASS_IMPORT __DECLSPEC (DLLIMPORT)
SO, WHEN EXPORTINGUR CLASS past Our dll we want the class declarations from the dll to look like this: -
Class __declspec (dllexport) CMYCLASS: Public COBject
{
...
}
AND, WHEN IMPORTING OUR C Classes Into Our Application We Want The Class Declarations from The DLL To Look Like this: -
Class __Declspec (dllimport) CMYCLASS: Public COBJECT
{
...
}
OK, So Here's How I do things.
In The Stdafx.h File for the Export DLL, Include Two #defines at the Bottom of The File THIS: -
#define _mylib_dllapi_
#define _mylib_noautolib_
Now, In the main header for your dll, Say Mylib.h (The Main 'Point of Entry' Header for Your DLL That You Will Include In You Application Later), Add The Following At The top: -
// The folload will ensure That We Are Exporting Our C Classes WHEN
// building the dll and import the classes when build an application
// Using this DLL.
#ifdef _mylib_dllapi_
#define mylib_dllapi __declspec (dllexport)
#ELSE
#define mylib_dllapi __declspec (dllimport)
#ENDIF
// the folowing will ensure this yuan, another
// DLL) Using this DLL, The appropriate .lib file will automaticly be used
// willing.
#ifndef _mylib_noautolib_
#ifdef _Debug
#pragma comment (Lib, "MYLIBD.LIB")
#ELSE
#pragma comment (Lib, "MYLIB.LIB")
#ENDIF
#ENDIF
Now, just declare all the C classes you want exported from the DLL like this :-( Note: Any C classes not declared with MYLIB_DLLAPI will not be exported from the DLL) class MYLIB_DLLAPI CMyClass: public CObject
{
...
}
SO, How does it work?
When Building your dll, _mylib_dllapi_ is defined in the dll's stdafx.h file, so mylib_dllapi is life, so mylib_dllapi is life, so mylib_dllapi is life, so mylib_dllapi is life, so mylib_dllapi is life, SO mylib_dllapi is life, so mylib_dllapi is life, SO mylib_dllapi is life, so mylib_dllapi is the deathd as __declspec (dllexport) and your c classes will be exported.
When Building your application, _mylib_dllapi_ isn't defined, so mylib_dllapi will be defined as __declspec (dllimport) and your classes will be imported.
The other nifty part is the _MYLIB_NOAUTOLIB_. If _MYLIB_NOAUTOLIB_ is not defined, (ie when building your application), an entry like #pragma comment (lib, "mylibd.lib") appears which tells the linker to automatically link in your DLL's. LIB File. Hence, There's no need to add the .lib file to the object / library modules section in your application project Link Settings (Sometting I Invariable Forgot To!).
The above is basically a 'set and forget' technique. All you'll ever need to do to use you extension DLL is just include it's header in your application, and all the ugly class export / import stuff is sorted for you.
(I can't Remember WHERE I Picked Up this Technique Originally, But Full Credit To It's Originator As It's Proved Invaluable over the years.)
