非MFC工程中使用MFC库

需求说明

C++工程的类型有很多，从VS(或VC)可以看到常见的有:Win32 Console Application、MFC Application、Win32 Project等。在创建MFC工程时，通过IDE的向导会自动帮我们创建相应的类文件和包含必需的头文件，但有时候我们需要在非MFC工程中包含MFC的库。至于为什么会有这个需要，为何不在一开始就创建MFC工程呢？可能有两种原因：1.在MFC工程会产生很多向导生成的代码以及资源文件，如基于单文档的工程会有View,Doc等类，很多时候我们并不需要这些东西，只需要一个空工程就可以了。2.使用第三方框架创建的工程，我们很难更改它的工程属性(如用Firebreath开发浏览器插件，通过脚本文件firebreath会自动帮我们生成VS下的工程)。

常见问题

在非MFC工程中使用MFC的库就需要包含相应的头文件，经常会遇到下面这个问题：

fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]
fatal error C1189: #error : WINDOWS.H already included. MFC apps must not #include

问题分析

对于第1个问题，很简单：

选中工程名右键属性(Project)，在Properties\Configuration Properties\General\Use of MFC中选择Use MFC in a Shared DLL 

出现上面第2个问题主要是因为包含头文件的顺序不对。为什么包含WINDOWS.H的时候会有顺序要求，网上有一段传播的非常广泛解释：

 如果在MFC工程中#include   <windows.h>，那么会有以下编译错误（因为afxwin.h文件中包含了afx.h，afx.h文件中包含了afxver_.h，afxver_.h中包含了afxv_w32.h，而afxv_w32.h中包含了windows.h，请看以下分析）：

  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>         
  如果编译器在编译afxv_w32.h文件之前编译了windows.h文件，编译器会报上面的错误，因为在afxv_w32.h文件中有下面的一句预编译报警：   
  #ifdef   _WINDOWS_   
  #error   WINDOWS.H   already   included.     MFC   apps   must   not   #include   <windows.h>   
  #endif   

  问题在于为什么afxv_w32.h中要有这么一句预编译处理。看了afxv_w32.h和windows.h文件就有点明白了。   
  在afxv_w32.h中有下面的预编译语句：   
  ...   ...   
  #undef   NOLOGERROR   
  #undef   NOPROFILER   
  #undef   NOMEMMGR   
  #undef   NOLFILEIO   
  #undef   NOOPENFILE   
  #undef   NORESOURCE   
  #undef   NOATOM   
  ...   ...   
  在afxv_w32.h中还有一句：   
  #include   "windows.h"   

  而在windows.h文件中有下面的预编译语句：   
  ...   ...   
  #define   NOATOM   
  #define   NOGDI   
  #define   NOGDICAPMASKS   
  #define   NOMETAFILE   
  #define   NOMINMAX   
  #define   NOMSG   
  #define   NOOPENFILE   
  ...   ...   

  注意到在windows.h的开头有防止windows.h被重复编译的预编译开关：   
  #ifndef   _WINDOWS_   
  #define   _WINDOWS_   

  这样问题就明白了，虽然我不知道微软为什么要这么做，但是我知道如果在afxv_w32.h没有那句预编译报警，那么如果在编译afxv_w32.h之前   
  编译了windows.h，那么在windows.h中#define的NOATOM等宏就会被#undef掉，可能会导致相应的错误发生。   

  猜想原因可能如上所述，我的解决方法是，将包含有#include   “windows.h"的头文件放在所有包含的头文件的最后面，这样使得对afxv_w32文件   
  的编译处理发生在先，这样，由于在afxv_w32.h中已经包含了windows.h，那么宏_WINDOWS_将被定义，后继的#include   "windows.h"语句将形同虚设，   
  上面的编译报警也不会发生了。我觉得这种处理要比将所有的#include   "windows.h”语句删掉要好一点。   

  一句话，编译器必须在编译windows.h之前编译afxv_w32.h,因为我不是十分清除什么时候afxv_w32.h会被编译，所以我将可能包含有#include   "windows.h"的头文件放在其他头文件之后#include。


参考解决方法

解决这个问题的总体思路是：把＃include <afxwin.h>的包含语句把到最前面。

sunshine1314 的博文《非MFC工程使用MFC库时的问题及解决办法》给出了一序列的解决方案，大家可能参考一下，也许能解决你们的问题。但我当时通过这一系列方法还是没能解决我的问题。

非MFC工程中使用MFC库

猜你喜欢