🔒 Locked

cannot convert char* to LPCWSTR

Started by tehmatt Jul 13, 2006 at 1:39 AM 3 replies 24.5k views

Original Post

Jul 13, 2006 at 1:39 AM

Hey, was wondering if anyone could spare a cople seconds of time to give me hand. I'm trying to learn the basics of visual c++ and make a program to simply create a window. I can get everything to work except for giving windows class names and captions. My code for it is as follows: const char *WindowClass = "Main"; const char *WindowCaption = "Main Window"; then in my int PASCAL WinMain function I have window.lpszClassName = WindowClass; I'm getting an error that says error C2440: '=' : cannot convert from 'char *' to 'LPCWSTR' I was under the impression that LPCWSTR and a pointer to const char were basicly interchangable. I can solve the problem(kind of) by typecasting it, and changing the line to read: window.lpszClassName = LPCWSTR(WindowClass); It gets rid of the error, but dosnt really solve the problem, seeing as how you just end up with a bunch of garbage where the name should be. Thanks :)

v0dKA

Jul 13, 2006 at 1:44 AM

You have UNICODE defined (it is defined by default). Read here about a similar problem: http://www.gamedev.net/community/forums/viewreply.asp?ID=2677680.

Endurion

Jul 13, 2006 at 1:44 AM

LPCWSTR is a pointer to a WCHAR.

I guess you're using Visual Studio 2005 which defaults all projects to Unicode. You can change that setting in the projects properties to MBCS code to use char* again.

You can also learn something new and use Unicode. In that case you have to use WCHAR* (or better for Windows programming TCHAR*).

To get a string literal to Unicode encoding you have to use the L macro:

WCHAR* WindowCaption = L"Main Window"

To make your code usable in both Unicode as well as MBCS setting you can use TCHAR* and the _T macro:

TCHAR* WindowCaption = _T( "Main Window" ).

Do NOT simply cast, as you noticed, that doesn't work.

tehmatt

Jul 13, 2006 at 1:49 AM

OK, thanks for the help. I'll have to go learn about Unicode now it looks like.

Sevans

Jul 13, 2006 at 8:58 AM

Ah, yes I ran into this problem very recently myself, you can find the thread of it here.

But here is the (awesome) answer that I got (from Pat) which helped me understand what was going on and why to use UNICODE.

Quote:

As a sidenote, let me explain the issue a little more detailed so you understand what's really going on.
The Win32 API headers defines a macro for each API function that has one or more string arguments or returns a character pointer. The actual implementation exists in two versions - one ASCII and one UNICODE version. These versions are suffixed by a single letter to indicate the string type.
Example:
MessageBox -> the macro you are used to

MessageBoxA -> the ASCII version that you propably know and use, takes char* arguments, e.g. char const * title = "Some Text"

MessageBoxW -> the UNICODE version; same as MessageBoxA, but expects UNICODE input, e.g. wchar_t const * title = L"Some Text"

The header that defines the macro now looks at the character set that is used by examining the macro _UNICODE (or _UNICODE_) and maps the corresponding function:

#ifdef _UNICODE
# define MessageBox MessageBoxA
#else
# define MessageBox MessageBoxW
#endif
The same is done for any struct that contains C-strings.
So far so good. Now why should you prefer Unicode? First of all, since the introduction of Windows NT (which Windows 2000, XP, 2003, and later are build on), the kernel uses UNICODE internally. This means that the ASCII versions convert the input to unicode at some point anyway, so you might as well use it, too.

Secondly, UNICODE avoids any problems with characters that are outside of the default ASCII set (e.g. character values >128), which are otherwise mapped to whatever charset the user has installed. This can lead to problems with non-English OS versions as the extended ASCII character set (128-255) differs slightly from region to region.

Last but not least, the Hungarian Notation used by the Win32 API indicates the type of the data as well. So if the compiler complains about a missing cast, you can easily spot the requested type by looking at its name. For example LPCSTR stand for "Long Pointer [to] Const STRing". The "Long"-part is an artifact from the 16-bit era and can safely be ignored. the const string part tells you that the ASCII character set is used and that the data will not be modified (i.e. const char *).
LPCWSTR, however, is almost the same with the exception that it's a "Wide STRing", e.g. UNICODE.

If you are still having problems take a look at my thread about it and see if any of those responses help.

GL to ya,

-sevans

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.