Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: sethjackson on September 05, 2006, 08:40:53 pm

Title: Rev 2954 ANSI mode
Post by: sethjackson on September 05, 2006, 08:40:53 pm
Hey in this revision C::B won't compile.

In sdk\globals.cpp line 601

Code: cpp
hinstDll = LoadLibrary(L"comctl32.dll");

It works if you take the L away of course. ;)

Code: diff
Index: src/sdk/globals.cpp
===================================================================
--- src/sdk/globals.cpp (revision 2954)
+++ src/sdk/globals.cpp (working copy)
@@ -598,7 +598,11 @@
     bool result = false;
     HINSTANCE hinstDll;
     DWORD dwVersion = 0;
+#if wxUSE_UNICODE
     hinstDll = LoadLibrary(L"comctl32.dll");
+#else
+    hinstDll = LoadLibrary("comctl32.dll");
+#endif
     if(hinstDll)
     {
         DLLGETVERSIONPROC pDllGetVersion;

Title: Re: Rev 2954 ANSI mode
Post by: killerbot on September 05, 2006, 10:08:58 pm
fixed in svn, not even needed to have the L for unicode, regular windows api, with regular english filename.
Title: Re: Rev 2954 ANSI mode
Post by: sethjackson on September 05, 2006, 10:20:14 pm
fixed in svn, not even needed to have the L for unicode, regular windows api, with regular english filename.

Well I hate to disagree with you, but try compiling it. ;)
No worky. ANSI mode works, but not Unicode.....

sdk\globals.cpp:601: error: cannot convert `const char*' to `const WCHAR*' for argument `1' to `HINSTANCE__* LoadLibrary(const WCHAR*)'
Title: Re: Rev 2954 ANSI mode
Post by: takeshimiya on September 05, 2006, 10:39:06 pm
fixed in svn, not even needed to have the L for unicode, regular windows api, with regular english filename.
Seth is right, remember that win32 haves usually ascii and unicode signatures.
Title: Re: Rev 2954 ANSI mode
Post by: stahta01 on September 05, 2006, 10:42:48 pm
Should it not be
hinstDll = LoadLibrary(_T("comctl32.dll"));

Per URL http://wiki.codeblocks.org/index.php?title=Unicode_Standards

Tim S
Title: Re: Rev 2954 ANSI mode
Post by: sethjackson on September 05, 2006, 10:44:25 pm
Should it not be
hinstDll = LoadLibrary(_T("comctl32.dll"));

Per URL http://wiki.codeblocks.org/index.php?title=Unicode_Standards

Tim S

No that is a wx macro..... The LoadLibrary function is a Windows API specific call. :)
Title: Re: Rev 2954 ANSI mode
Post by: takeshimiya on September 05, 2006, 10:58:24 pm
Should it not be
hinstDll = LoadLibrary(_T("comctl32.dll"));

Per URL http://wiki.codeblocks.org/index.php?title=Unicode_Standards

Tim S

No that is a wx macro..... The LoadLibrary function is a Windows API specific call. :)
And?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

"Implemented as LoadLibraryW (Unicode) and LoadLibraryA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode."

And BTW, _T() is not only a wx macro, it is commonly used in win32 & mfc programming and it serves for the same purpose.
Title: Re: Rev 2954 ANSI mode
Post by: sethjackson on September 05, 2006, 11:02:26 pm
Should it not be
hinstDll = LoadLibrary(_T("comctl32.dll"));

Per URL http://wiki.codeblocks.org/index.php?title=Unicode_Standards

Tim S

No that is a wx macro..... The LoadLibrary function is a Windows API specific call. :)
And?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/loadlibrary.asp

Implemented as LoadLibraryW (Unicode) and LoadLibraryA (ANSI).

And BTW, _T() is not only a wx macro, it is commonly used in win32 & mfc programming and it serves for the same purpose.


Right the Windows API have two versions normallly. A unicode, and a ANSI. Anyways I thought that _T() was wx only. So I thought that it wouldn't work for a Windows API call.

I stand corrected.  :oops:
Title: Re: Rev 2954 ANSI mode
Post by: killerbot on September 05, 2006, 11:08:03 pm
_T() version committed, strange that it's not needed then for GetProcAddress() ...
Title: Re: Rev 2954 ANSI mode
Post by: sethjackson on September 05, 2006, 11:11:20 pm
_T() version committed, strange that it's not needed then for GetProcAddress() ...

Well at the risk of being wrong again I believe it is because that function is not implemented as Unicode.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getprocaddress.asp