I had no idea you could use literals the way you did and never thought to append them with += like that. |
You can only do it if you're using std::string. If you are using char arrays, you cannot append with +=. Just FYI.
I recommend using std::string because it's much easier, and much safer.
I do have a question about your mentioning of char* versus a TCHAR*. What exactly is the difference? |
TCHARs are backwards compatibility weirdness.
In the very early days of Windows, there was no Unicode. Really old programs used "code pages" to print non-ascii or foreign alphabet glyphs to the screen.
Then later Windows built itself on top of UTF-16, meaning that all the strings it deals with internally are stored in UTF-16. The thing with UTF-16 is that it is typically
2 bytes per character, whereas chars are only 1 byte.
This presented a problem, because all of the WinAPI functions which take strings (like SetWindowText) currently took "narrow" (1 byte wide) strings, whereas they needed to change to take "wide" (2 byte wide) strings.
MS's solution to this was to create a 3rd transitory type called a TCHAR which could act as either a narrow or wide character depending on your build settings. It then redefined all its string functions to take TCHARs instead of chars so that they could optionally support wide strings if you tweak your compiler settings.
In the past, if programmers used this tool correctly, it allowed them to flip a switch to enable/disable Unicode support in their program. Disabling Unicode support might have had some performance benefit in a time where computers were not as fast as they are now. However in modern times, such a switch -- and therefore TCHARs -- are near useless and working with them is more of a hassle than they're worth.
Anyway... the just of it is there are 3 character types:
1)
char
, which uses 'narrow' / non-Unicode strings
2)
wchar_t
or
WCHAR
, which uses 'wide' / UTF-16 strings
3)
TCHAR
which is #defined as either char or wchar_t depending on your compiler settings.
And all WinAPI functions/structs which deal with strings have 3 forms to match:
1)
SetWindowTextA
takes char strings (LPCSTR)
2)
SetWindowTextW
takes wchar_t strings (LPCWSTR)
3)
SetWindowText
takes TCHAR strings (LPCTSTR)
In practice, the TCHAR function really just gets #defined as one of the other forms depending on the compiler settings. windows.h does something like this:
1 2 3 4 5
|
#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif
|
If passing char strings to SetWindowText works, it's because your compiler settings happen to have unicode disabled. If that were to change (or if someone else were try to build your code with that setting set differently), you'd see a swarm of errors.
The right way to deal with this is to just match the string types correctly regardless of the compiler setting. That way it'll always work. So if you have char strings... use the char form of the function (the 'A' form).
LONG STORY SHORT
Different string types use different functions.
1 2 3 4 5 6 7 8
|
// only call SetWindowText with TCHAR strings
SetWindowText( wnd, _T("foobar") );
// only call SetWindowTextA with char strings
SetWindowTextA( wnd, "foobar" );
// only call SetWindowTextW with wchar_t strings
SetWindowTextW( wnd, L"foobar" );
|