Sorry for my late answer. I overlooked your reply. The CStringT class constructors and assignment operators accepting the LPCSTR and LPCWSTR types will convert the string if it does not match (when assigning LPCWSTR to a CStringA object it is converted to ANSI and when assigning LPCSTR to a CStringW object it is converted to Unicode). The conversion is internally performed using WideCharToMultiByte() and MultiByteToWideChar() with code page CP_THREAD_ACP (when using Visual Studio 2003 and later; with older versions or manually set preprocessor definition _CONVERSION_DONT_USE_THREAD_LOCALE, CP_ACP is used). See the ATL/MFC source files cstringt.h and atlconv.h if you are interested in how the conversions are performed. If you are not calling SetThreadLocale() within your app, the thread will use the system locale. If the results from using WideCharToMultiByte() and CStringT constructors are different, you have passed a code page number that differs from the default code page of the used locale. So you may post your settings here or check it yourself:
The code page passed to WideCharToMultiByte()
The code page used by the CStringT class
To get the code page used by the CStringT class use this code snippet (assuming CP_THREAD_ACP is used):
// Default ANSI code page
int nCP = ::GetACP();
// Returns same as GetSystemDefaultLCID() when SetThreadLocale() has not been called.
LCID nLCID = ::GetThreadLocale();
TCHAR szACP[7];
if (::GetLocaleInfo(nLCID, LOCALE_IDEFAULTANSICODEPAGE, szACP, 7) != 0)
nCP = _tstoi(szACP);
Now compare nCP with the value passed to WideCharToMultiByte(). All these different locales and code pages may be confusing. So I will sum up the settings that may effect your conversions:
The system locale including its default ANSI code page
The user's locale including its default ANSI code page
The thread's locale including its default ANSI code page
The code page used by the CStringT class
The code page passed to conversion functions in your code