Passing String Pointers to Functions

[anachronon]

A quick question that I hope is simple. It is a problem that I keep running across. So often, when passing string pointers to Windows functions, I get this error:

argument of type "wchar_t *" is incompatible with parameter of type "LPWSTR"

What is the best way to resolve this error? I can declare the variable as a string pointer. But, memory has not been allocated. What is the difference between "wchar_t *" and "LPWSTR". Aren't all pointers in 32-bit Windows, "long"?

[helios]

LPWSTR and wchar_t * should be equivalent types. Are you sure that's the actual error? What's the code that triggers it?

[Thomas1965]

This article explains all the string types in the Win API
https://www.codeproject.com/Articles/76252/What-are-TCHAR-WCHAR-LPSTR-LPWSTR-LPCTSTR-etc

[freddie1]

As helios said, they are indeed the same. From Microsoft's documentation....

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/50e9ef83-d6fd-4e22-a34a-2c6b4e3c24f3

...the gist of which is....

typedef wchar_t* LPWSTR, *PWSTR;

What development environment are you using anachronon? I'd be curious to see more details of how you are getting this error.

[anachronon]

Indeed, "wchar_t*" and "LPWSTR" are supposed to be the same thing. Yet, "Microsoft Visual C++ 2019" gives me a fatal error, every time I try to pass a pointer to an existing string, to a function that takes a "PWSTR" or "LPWSTR". The greatest problem is with Windows canned functions, where I cannot change the argument types, to get around the errors. Here is a classic code example:

wchar_t  szSampleString[64];    //string defined

...(more code, creating the string)...

MessageBox(NULL, szSampleString, L"File Path", MB_OK);

Typical error messages are as follows:

argument of type "wchar_t *" is incompatible with parameter of type "LPWSTR *"

cannot convert argument 2 from 'wchar_t [64]' to 'LPWSTR *'

[deleted account xyzzy]

What compiler are you using, and are you defining the compiler to use Unicode character set?

Visual Studio 2019 has zero heart-burn with this (it defaults to using Unicode when creating a Win32 desktop app):

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow)
{
   wchar_t  szSampleString[64] = { L"Hello World!" };

   MessageBoxW(NULL, szSampleString, L"File Path", MB_OK);

   return 0;
}

[deleted account xyzzy]

You can also use WCHAR for Win32 apps instead of wchar_t.

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow)
{
   WCHAR szSampleString[64] = { L"Hello World!" };

   MessageBoxW(NULL, szSampleString, L"File Path", MB_OK);

   return 0;
}

WCHAR is a typedef for wchar_t.

[anachronon]

Y'all are not gonna believe this one! I tried adding a datatype modifier to my string pointer, to see if that might fix the problem (even though, theoretically, I shouldn't have to):

MessageBox(NULL, (LPWSTR) szSampleString, L"Message", MB_OK);

Well, the error that I got now, is beyond belief!:

argument of type "LPWSTR" is incompatible with parameter of type "LPWSTR *"
cannot convert argument 2 from 'LPWSTR' to 'LPWSTR *'

Really?! I knew that computers were dumb. But, I didn't think that they were that dumb. Or, is my compiler somehow broken. It's Microsoft Visual Studio 2019, "Community edition".

[Ganado]

That's called casting, which is very powerful and especially a C-style one, "(cast)variable", can be very dangerous.

Your error is the equivalent of saying:

cannot convert int into int*

e.g.

int apple = 4;
int* ptr = apple;

I hope that will never compile on any compiler.

...that being said, based on your previous message, I'm still not sure what's going on.

(1) Does this compile for you?

#ifndef UNICODE
#define UNICODE
#endif
#include <windows.h>

int main()
{
    WCHAR sampleString[100] = L"Hello, world!";
    MessageBox(NULL, sampleString, L"Message", MB_OK);
}

(2) Does FurryGuy's code compile for you?

(3) Can you show a full, minimal example that reproduces your error? That's what we really need to help you.

[deleted account xyzzy]

My compiler -- VS 2019 Community -- has. as I said previously, zero heart-burn with the code I wrote. Maybe try changing your message-box function call to MessageBoxW instead of the generic MessageBox?

If you are going to use Unicode/wide characters you should use the specific Unicode/wide character versions of all the Win32 API functions you are using.
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messageboxw

How did you create your project's solution files in VS? That could be another source of your problems.

Try starting a NEW project/solution, using the Windows Desktop Wizard template option. I used that when I wrote the code I posted.

I chose Desktop Application (.exe) as the application type, selecting Empty project as an additional option.

Added a new C/C++ file and wrote the code I posted above. Not a single problem except when I mistyped.

I duplicated the above steps yet again and had zero problems. There is likely something that got knocked out of whack with your solution's support files. It can happen.

When mashing together console apps I use the Empty Project template and add header and source files as I need them.

[anachronon]

Oddly, now that I rebooted the computer, everything seems to work properly. Don't know why that is, unless it was some kind of memory overrun. This isn't the fanciest laptop ever made. Anyway, here is one of the codes that kept giving me errors (it works now):

#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
	wchar_t szSampleString[64];
	int iValue = 25;

	wsprintf(szSampleString, L"Value = %d", iValue);

	MessageBox(NULL, szSampleString, L"Message", MB_OK);
	
	return 0;
}

When run on its own, it seems to do fine. However, when run in a complex program, as a debugging tool (where iValue is used to check a problem variable) I often get the errors that I described.

Another issue that has often caught me off-guard: Some Windows functions take pointers to pointers. Any reason for this? One place that I came across this, was while trying to learn about dialog boxes.

[deleted account xyzzy]

now that I rebooted the computer

That kick in the digital butt can do wonders more often than not.

Some Windows functions take pointers to pointers.

The Win32 API can be hard to fathom at times. Just remember it is written for C, not C++.

MFC is the Win32 API written for C++, and is just as much an organizational nightmare.

[helios]

Some Windows functions take pointers to pointers. Any reason for this? One place that I came across this, was while trying to learn about dialog boxes.

There's basically two reasons the WinAPI takes pointers. Either the function in question needs to accept a variable number of values (e.g. a string or an array of numbers or structs), or the function needs to return a value to the caller (by convention, the return value proper is always a result code). A pointer to pointer is very often a case of the latter, where the value that needs to be returned happens to be a pointer.