Using the MFC library in non-MFC projects

Directory (?) [-]

1. Requirements Description
2. Problems
3. Problem analysis
4. Refer to Workaround
5. My solution
6. The principle of STDAFXH

Requirements Description

There are many types of C + + projects, from VS (or VC) you can see common: Win32 Console application, MFC application, WIN32 project, etc. When you create an MFC project, the IDE's wizards automatically help us create the appropriate class files and include the necessary header files, but sometimes we need to include the MFC libraries in non-MFC projects. As to why this is necessary, why not create the MFC project from the beginning? There are two possible reasons: 1. In the MFC project will generate a lot of wizard-generated code and resource files, such as the project based on a single document will have View,doc and other classes, many times we do not need these things, only need an empty project to be. 2. Using a project created by a third-party framework, it is difficult to change its engineering properties (such as using Firebreath to develop a browser plugin, and the script file Firebreath will automatically help us build the project under VS).

Problems

Libraries that use MFC in non-MFC projects need to contain the corresponding header files and often encounter the following problem:

1. fatal error C1189: #error: Building MFC Application With/md[d] (CRT DLL version) requires MFC shared DLL version. P Lease #define _afxdll or do not use/md[d]

2. fatal error C1189: #error: WINDOWS.  H already included. MFC apps must not #include <windows.h>

Problem analysis

For question 1th, it's simple:

Select the project name right-click Property (Project), in Properties\configuration Properties\general\use of MFC, choose the use MFC in a Shared DLL

The 2nd problem arises primarily because the order in which the header files are contained is incorrect. Why include WINDOWS.H when there will be a sequence of requirements, the Internet has a very broad interpretation of the spread:

If you include <WINDOWS.H> in the MFC project, then there will be a compilation error (because the AFXWIN.h file contains the Afx.h,afx.h file that contains the afxv_ contained in the Afxver_.h,afxver_.h W32.h, while the afxv_w32.h contains Windows.h, see the following analysis):

Compile error:
C:\Program Files\Microsoft Visual Studio\vc98\mfc\include\afxv_w32.h (14):
Fatal error C1189: #error: WINDOWS.     H already included. MFC apps must not #include <windows.h>
If the compiler compiles the windows.h file before compiling the Afxv_w32.h file, the compiler will report the error above because there is a pre-compiled alert in the Afxv_w32.h file:
#ifdef _windows_
#error WINDOWS.     H already included. MFC apps must not #include <windows.h>
#endif

The question is why this is a pre-compilation process in Afxv_w32.h. Look at the afxv_w32.h and Windows.h file is a bit clear.
There are the following precompiled statements in Afxv_w32.h:
...   ...
#undef Nologerror
#undef Noprofiler
#undef nomemmgr
#undef Nolfileio
#undef Noopenfile
#undef Noresource
#undef Noatom
...   ...
In the afxv_w32.h, there is another sentence:
#include "Windows.h"

In the Windows.h file, you have the following precompiled statement:
...   ...
#define Noatom
#define Nogdi
#define Nogdicapmasks
#define Nometafile
#define Nominmax
#define Nomsg
#define Noopenfile
...   ...

Note that at the beginning of windows.h there are precompiled switches that prevent Windows.h from being repeatedly compiled:
#ifndef _windows_
#define _windows_

The question is clear, though I don't know why Microsoft did it, but I know that if there is no pre-compiled alarm in afxv_w32.h, then if you do before compiling afxv_w32.h
Compiled windows.h, then windows.h in the # define Noatom and other macros will be #undef out, may cause the corresponding error occurred.

The reason for conjecture may be as above, my workaround is to place the header file containing the # include "Windows.h" on the last side of all included header files, so that the Afxv_w32 file
Compile processing occurs earlier, so that, because the windows.h is already included in the Afxv_w32.h, the macro _windows_ will be defined, and the subsequent # include "windows.h" statements will be in the form of a dummy,
The above compilation alarm will not happen. I think this is better than deleting all the # include "windows.h" statements.

In a word, the compiler must compile afxv_w32.h before compiling windows.h, because I am not quite clear when afxv_w32.h will be compiled, so I will probably include a header file with # include "Windows.h" after the other header file # Include

Refer to Workaround

The general idea to solve this problem is to put the inclusion statement of # include <afxwin.h> to the front.

Sunshine1314 's Blog "Problems and solutions when using MFC libraries for Non-MFC projects" gives a sequence of solutions, which may be useful to you, perhaps, to solve your problems. But I still failed to solve my problem through this series of methods.

My solution

My question is: developing browser plugins with Firebreath, using fbgen.py and Prep2010.cmd scripts to help us build a VS2010-based project (no stdaf.h in this project), We are going to get the HDC in MFC and use the MessageBox in this project, so we encounter the problem mentioned above.

Solution:

Manually adding stdafx.h and stdafx.cpp files uses the precompilation mechanism, which contains <afxwin.h> at the front of stdafx.h. So the problem becomes the stdafx.h principle and the manual add StdAfx.h file and the corresponding configuration. Below we take the textproject of the Win32 Console application project as an example to illustrate the process.

1. Create the textproject of the Win32 Console application project in VS2010 and create the stdafx.h and Stdafx.cpp automatically generated by the wizard, eliminating the manual addition process. If your project does not have these two files can be created manually.

2.stdafx.h and Stdafx.cpp These two files have been created and added to the project, which are related to the formulation below.

2.1 Select the project name, right-click Property (Properties), select Use (/yu) in the precompiled header/precompiled header, precompiled header file to fill in stdafx.h. Set the project compile time using precompiled Header file StdAfx.h (the case of filenames in VS is not sensitive, that is, StdAfx.h and stdafx.h are equivalent).

2.2 Select the Stdafx.cpp file, right-click Properties, select Create (/yc) in the precompiled header/precompiled header, precompiled header Fill in file stdafx.h. The purpose of this setting is to create a. pch file (the extension PCH represents a precompiled header file) each time the Stdafx.cpp file is compiled.

3. The development of the stdafx.h contains <afxwin.h> documents:

#include <afxwin.h>

4. At this point in our main function write the following sentence, you can pop up a message box:

AfxMessageBox (L "Non-MFC Project using MFC Library", MB_OK, 0);

The principle of Stdafx.h

See the next article on the principles of the precompiled Header file (stdafx.h) for stdafx.h.

Using the MFC library in a non-MFC project