Error: Cannot Convert 'Const Wchar_T [13]' to 'Lpcstr {Aka Const Char*}' in Assignment

cannot convert 'wchar_t*' to 'LPCSTR' {aka 'const char*'}

Well i see that pBuffer have some issues and thats propably becasue you are using multibyte character set i compiled this code with multibyte character set and i get same errors like you need to change multibyte character set to Use Unicode Character Set and it should solve your problem. Its viusal studio option :)

cannot convert 'const char*' to 'LPCWSTR {aka const wchar_t*}'

The Windows CreateFile function is actually a macro that expands to one of:

  • CreateFileA, which takes a file path of type const char*
  • CreateFileW, which takes a file path of type const wchar_t*.

(The same is true for most of the functions in the Windows API that take a string.)

You're declaring the parameter const char* ComName, but apparently compiling with UNICODE defined, so it's calling the W version of the function. There's no automatic conversion from const wchar_t* to const char*, hence the error.

Your options are to:

  1. Change the function parameter to a UTF-16 (const wchar_t*) string.
  2. Keep the char* parameter, but have your function explicitly convert it to a UTF-16 string with a function like MultiByteToWideChar.
  3. Explicitly call CreateFileA instead of CreateFile.
  4. Compile your program without UNICODE, so that the macros expand to the A versions by default.
  5. Kidnap a prominent Microsoft developer and force him to read UTF-8 Everywhere until he agrees to have Windows fully support UTF-8 as an “ANSI” code page, thus freeing Windows developers everywhere from this wide-character stuff.

Edit: I don't know if a kidnapping was involved, but Windows 10 1903 finally added support for UTF-8 as an ANSI code page.

error: cannot convert 'const CHAR**' {aka 'const char**'} to 'LPCSTR' {aka 'const char*'} in C++

The line:

LPCSTR wsKey[MAX_PATH] = {"Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"};

declares wsKey to be an array of MAX_PATH character pointers, the first of which points to the given string literal. If this is really what you want, then the second argument to your SHRegGetValue call should be that first element: wsKey[0].

However, what is more likely, is that you need wsKey to be an array of MAX_PATH charactersnot pointers. Like this:

const CHAR wsKey[MAX_PATH] = "Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings"; // Note the removal of the enclosing {...} braces!

You also have an error with the third parameter to SHRegGetValue: this should be a char (or CHAR) string, not a WCHAR string (you are mixing up the ANSI and Unicode versions of the call). Declare wsValue like this, to use the ANSI version:

CHAR wsValue[MAX_PATH] = "ProxyEnable";

Alternatively, if you intend to use the wide-character (Unicode) version, then you need to change your wsKey to a wide-character string. (This seems more likely, given the variable names.)

const WCHAR wsKey[MAX_PATH] = L"Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings";
WCHAR wsValue[MAX_PATH] = L"ProxyEnable";

Cannot convert argument 1 from 'const char [5]' to 'LPCTSTR'

SetWindowTextW() takes a character pointer to the string's data where your string data consists of regular chars, but your function most likely expects a unicode string, so you cannot input string types directly. You need to use L"thisismystring"

strcmp error 'WCHAR [260]' to 'const char *'

It does not make sense for this to work in debug mode; that must be a mis-observation.

WCHAR is a Microsoft alias for wchar_t (or unsigned short if needs be) (ref).

You have an array of these things.

Said array will never be compatible with const char*, because wchar_t and char are two different things. So, you cannot pass your array to functions that require const char*, like strcmp.

C (and, by extension, C++) also provides a wide-character version of strcmp that you can use: wcscmp.

Cannot convert 'const char*' to 'WCHAR*' in argument passing

You are most likely using one of the Visual Studio compilers, where in Project Settings, there is a Character set choice. Choose from:

  • Unicode character set (UTF-16), default
  • Multi-Byte character set (UTF-8)
  • Not Set

Calling functions that accept strings in the Unicode setting requires you to make Unicode string literals:

"hello"

Is of type const char*, whereas:

L"hello"

is of type const wchar_t*. So either change your configuration to Not set or change your string literals to wide ones.

Adding new user gives error a value of type const wchar_t cannot be assigned to entity of type LPWSTR

The usri_name and usri_password fields are pointers to non-const Unicode buffers, but you are trying to assign string literals to them, which are const data.

So, you can either:

  • const_cast away the const-ness of the literals (be extra careful with this!):
ui.usri1_name = const_cast<wchar_t*>(L"istech");
ui.usri1_password = const_cast<wchar_t*>(L"p@ssword");
  • copy the literals' content into local wchar_t[] arrays:
wchar_t name[] = L"istech";
wchar_t pass[] = L"p@ssword";

ui.usri1_name = name;
ui.usri1_password = pass;

cannot convert parameter 1 from 'const char *' to 'LPCWSTR'

Most of the Windows APIs that take strings have two versions: one that takes char * and one that takes WCHAR * (that latter is equivalent to wchar_t *).

SetWindowText, for example, is actually a macro that expands to either SetWindowTextA (which takes char *) or SetWindowTextW (which takes WCHAR *).

In your project, it sounds like all of these macros are referencing the -W versions. This is controlled by the UNICODE preprocessor macro (which is defined if you choose the "Use Unicode Character Set" project option in Visual Studio). (Some of Microsoft's C and C++ run time library functions also have ANSI and wide versions. Which one you get is selected by the similarly-named _UNICODE macro that is also defined by that Visual Studio project setting.)

Typically, both of the -A and -W functions exist in the libraries and are available, even if your application is compiled for Unicode. (There are exceptions; some newer functions are available only in "wide" versions.)

If you have a char * that contains text in the proper ANSI code page, you can call the -A version explicitly (e.g., SetWindowTextA). The -A versions are typically wrappers that make wide character copies of the string parameters and pass control to the -W versions.

An alternative is to make your own wide character copies of the strings. You can do this with MultiByteToWideChar. Calling it can be tricky, because you have to manage the buffers. If you can get away with calling the -A version directly, that's generally simpler and already tested. But if your char * string is using UTF-8 or any encoding other than the user's current ANSI code page, you should do the conversion yourself.

Bonus Info

The -A suffix stands for "ANSI", which was the common Windows term for a single-byte code-page character set.

The -W suffix stands for "Wide" (meaning the encoding units are wider than a single byte). Specifically, Windows uses little-endian UTF-16 for wide strings. The MSDN documentation simply calls this "Unicode", which is a little bit of a misnomer.



Related Topics



Leave a reply



Submit