Reputation: 3728
UTF-8 everywhere makes a strong case to shun the Microsoft TCHAR
, _T()
, LPCTSTR
and so forth completely, to push wchar_t
aside as well, and bravely embrace a world of UTF-8 strings based on a narrow char
type.
Which seemed fine until I came to the MFC DDX_Text()
macro for getting a CString
both in and out of an edit control. Is there any reasonable way to:
CStringA myString
intended as an UTF-8 string (or as an ASCII/ANSI string as a degenerate case)UNICODE
definedmyString
through suitable conversions and/or temporary variables and into the third parameter to DDX_Text()
, and get sensible results to and from the associated edit control?If not, how would you recommend handling string input/output via edit controls if your application wanted to use UTF-8 (or ASCII/ANSI in the degenerate case)?
(P.S. this is motivated by Visual Studio 2013 encouraging Unicode-only use of MFC. Given an MFC app, and a desire to use VS2013, this requires UNICODE
to be defined... or to cling on to a deprecated way of doing things.)
Upvotes: 0
Views: 1170
Reputation: 6556
Windows internally uses UTF-16 as UNICODE standard. So you will have to follow that and use CString which is defined as CStringW in UNICODE. Also you have to use _T() macro. All Windows common controls like Edit Box, List Box, etc are using UNICODE as well.
I'd suggest using UTF-8 for networking stuff only.
// UTF8 conversion
CStringA CUtility::UTF16toUTF8(const CStringW& utf16)
{
return CW2A(utf16, CP_UTF8);
}
CStringW CUtility::UTF8toUTF16(const CStringA& utf8)
{
return CA2W(utf8, CP_UTF8);
}
Upvotes: 2