using text string functions in Win32

[dodge55]

So, I have an embedded system that saves data in (unsigned char) format to an SD card. This data is read into my Win32 app into a structure (all unsigned char fields). One particular field in the structure is a 16x40 text field of location data (Locations[16][40]. When I use this data in the app, I convert to WCHAR, since string functions have UNICODE parameters. Works great. No issues.

I need to 'fake' some data during testing, so that I can handle extreme cases. After reading in the data from the SD card, but before I use it, I would like to add some text data to my 16x40 text array within the structure. Visual Studio won't let me use standard strcpy or strcpyn because they are deprecated functions and gives me an error. Using _CRT_SECURE_NO_WARNINGS isn't working either per the error message advise. The only way I can get data into my Locations array, prior to conversion, is:

void Fake_Data()
{
Locations[0][0] = 'L';
Locations[0][1] = 'o';
Locations[0][2] = 'c';
Locations[0][3] = ' ';
Locations[0][4] = '1';
Locations[0][5] = 0; // setting one char at a time works
}

strcpy((char *)Locations[0],"Location 1"); // this compiles but gives deprecation

Any Unicode string functions (lstrcpy) seem to not want to copy single byte text data, even when casting.

This is what I want to do. It compiles, but doesn't fill in the structure properly.

lstrcpy((LPWSTR)Locations[0],L"Location 1");
lstrcpy((LPWSTR)Locations[1],L"Location 2");

Maybe a variation of this will compile and work. I just haven't found the right combination yet. Maybe, I have to write a function to do this and not in one step.

Any ideas on things I can try? The above will work. Just trying to be more efficient, but not necessary.

[kigar64551]

On the Windows platform, "ANSI" (multi-byte) strings use the char type and are 1 byte in size (per character*), but "Unicode" (UTF-16) strings use the wchar_t type and are 2 bytes in size (per character).

Note that, nowadays, char-based (multi-byte) strings are usually encoded in UTF-8, but it could be one of the "legacy" Codepages, such as ISO 8859-1 (aka Latin-1, aka Windows-1252), just as well.

You use the functions MultiByteToWideChar() and WideCharToMultiByte() to convert between char-based and wchar_t-based strings. Simply assigning a wchar_t to the value of a char does not work for anything but plain ASCII – it breaks (not only) for characters that are encoded as a sequence of multiple bytes !!!

See here for a proper example:
https://gitlab.xiph.org/xiph/opus-tools/-/blob/master/win32/unicode_support.c#L39


In MSVC, the "traditional" string functions from the C Standard Library, such as strcpy(), are deprecated – in favor of the "secure" versions, such as strcpy_s(). Just use the "secure" versions, if your code will only be compiled by MSVC. Otherwise, if you need to support other compilers too, then you can ignore (or even disable) the deprecation warning. lstrcpy() is from the Win32 API, not C Standard Library; better avoid using it.

Also note: If you are dealing with wchar_t (UTF-16) strings, then you must use the "wide string" functions wcslen(), wcscpy() or wcscpy_s() instead of the "normal" functions strlen(), strcpy() or strcpy_s() !!!

Likewise, lstrcpy() exists as lstrcpyA() and lstrcpyW() variants, for multi-byte and UTF-16 strings. In fact, lstrcpy() is just a macro that expands to either lstrcpyA() or lstrcpyW(), depending on configuration.

lstrcpy((LPWSTR)Locations[0],L"Location 1");

Do not cast the char* pointer to wchar_t* pointer. It may compile, but still is utterly wrong here :-(


* In fact, in multi-byte strings, a single character may actually occupy multiple chars (bytes) !!!

[jonnin]

As horrid as they are, if using MFC/ win32, use their CString (narrow or wide as needed) so you can work within their framework and it likely be the best option.

[dodge55]

Thanks for the responses. It looks like MultiBytetoWideChar and vice-versa would work. I just wrote 2 functions, CharToWChar and WCharToChar and they work fine. I went thru the debugger and made sure they were converted the way I wanted.