Cannot convert parameter from 'const char[20]' to 'LPCWSTR'

Question

When compiling this code:

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInsance,HINSTANCE hPrevInstance,PSTR cmdLine,int showCmd){
    MessageBox(0,"First Win32 Program","Window Tittle",MB_OK);
    }

I get the compiler error:

Error C2664: 'MessageBoxW': cannot convert parameter 2 from 'const char [20]' to 'LPCWSTR' 1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

What am I doing wrong?

Solution 1

You have UNICODE defined, so MessageBox is expecting a wide string.

Solution 2

By default UNICODE is defined in Visual Studio 2010. Either call MessageBoxA instead of using the MessageBox define or pass a wide string literal (L"First Win32 Program" and L"Window Title") or, if you really care about being able to build without UNICODE defined, use the _T macro around your string literals: _T("First Win32 Program") (this is the same as L"First Win32 Program" when UNICODE is defined, but it will be "First Win32 Program" when UNICODE is not defined).

For more information about UNICODE and how it affects what APIs are called, see this link: http://msdn.microsoft.com/en-us/goglobal/bb688113.aspx. Specifically, the sections below "Creating Win32 Unicode Applications".

On a side note: All Windows operating systems supported by Microsoft today are Unicode native. I would recommend to always favor the "wide" API. In this case, MessageBoxW, which is what MessageBox is defined to be when UNICODE is set. The days of using the _T macro and compiling without UNICODE defined should be behind us.

Comments

[Zan Lynx]

I hesitate to use my C++ dup-hammer on this but here's the oldest question on this I could find: stackoverflow.com/questions/667616/cast-to-lpcwstr

[Cody Gray]

Hmm, I always use the _T macro anyway. I'm not sure what the downside is, or why you'd prefer to use L, even if the non-Unicode days are behind us.

[Peter Huene]

There's no real downside except for what some might find to be clutter and the fact that if you forget to use it, you'll get compilation errors when UNICODE is defined or vice versa. Personally, I opt for the explicitness of calling the wide APIs and just using wide data types, which really just makes the UNICODE define useless.

[Bo Persson]

@Cody - One reason for using L instead of _T is that L is standard C++, and that we only target Windows versions with UNICODE defined. Unless you still do a lot of Windows 95, of course. :-)

[Charlie]

this was the solution for me