在Win32工程中使用GdiPlus

在vs直接建立的win32工程裏直接添加GdiPlus的相關支持文件:

#include <gidplus.h> using namespace gdiplus; #pragma comment(lib, "gdiplus.lib")

編譯器會報幾百個錯誤,都是些什麼"缺少類型說明符",語法錯誤或者標識符錯誤之類的.

一般這種情況都是由於頭文件引用缺少一些特殊的支持,或者引用順序錯誤導致的.

 

網上的解決辦法一般有兩種:

1.關閉#include <windows.h>前面的WIN32_LEAN_AND_MEAN定義;

2.在導入GdiPlus支持文件之前添加#include <comdef.h>.

 

這兩種解決辦法究竟有什麼不同呢?

我們參考windows.h的文件內容,中間關於WIN32_LEAN_AND_MEAN宏定義的部分是這樣寫的:

#ifndef WIN32_LEAN_AND_MEAN #include <cderr.h> #include <dde.h> #include <ddeml.h> #include <dlgs.h> #ifndef _MAC #include <lzexpand.h> #include <mmsystem.h> #include <nb30.h> #include <rpc.h> #endif #include <shellapi.h> #ifndef _MAC #include <winperf.h> #include <winsock.h> #endif #ifndef NOCRYPT #include <wincrypt.h> #include <winefs.h> #include <winscard.h> #endif #ifndef NOGDI #ifndef _MAC #include <winspool.h> #ifdef INC_OLE1 #include <ole.h> #else #include <ole2.h> #endif /* !INC_OLE1 */ #endif /* !MAC */ #include <commdlg.h> #endif /* !NOGDI */ #endif /* WIN32_LEAN_AND_MEAN */

中間並沒有關於comdef.h的內容.

不過我們打開comdef.h查看內容,發現裏面引用了ole2.h這個頭文件,而關閉WIN32_LEAN_AND_MEAN宏之後的windows.h也引用了這個頭文件.

於是我僅在GdiPlus支持文件之前添加#include <ole2.h>,代碼編譯成功.

 

打開ole2.h,可以發現裏面引用了objbase.h.

實際上直接在GdiPlus支持文件之前添加#include <objbase.h>,編譯就不會出錯了.

關於objbase.h,微軟的註釋是:"Component object model defintions",意思貌似是COM組件模型的基礎定義.

 

不過其實這個頭文件也不是最終需要的文件...

只要添加了objbase.h中引用的rpc.h,urlmon.h或propidl.h中的任意一個頭文件,GdiPlus編譯就不會再出錯.

urlmon.h和propidl.h引用了rpc.h與ole2.h,因此最終的頭文件應該還是rpc.h.可rpc.h中真正起作用的部分是哪裏呢?

打開rpc.h,就會發現其中有一段代碼:

#if !defined( RPC_NO_WINDOWS_H ) && !defined( MAC ) && !defined( _MAC ) && !defined(_KRPCENV_) #include <windows.h> #endif // RPC_NO_WINDOWS_H

測試一下就會發現,這段代碼纔是真正起作用的代碼=.=

很好,繞了一圈繞回來了...

 

也許真正讓GdiPlus通過的代碼就隱藏在那一堆頭文件的內容裏,又或者只有MS知道在哪裏...反正我是不想再深究了,呵呵