Kris wrote:
I'm trying to fix a bug where a TListView subitem needs to be able
to properly display extended ASCII characters.
You are passing an Ansi string literal where a System::String is expected.
To avoid any data loss, pass a Unicode string literal instead, eg:
item->SubItems->Add(L"FÑÙ"); // <-- notice the 'L' prefix
Or:
item->SubItems->Add(_D("FÑÙ"));
_D() is a C++Builder specific macro that tells the compiler to interpret
the literal using the same encoding that System::Char and System::String
use (in this case, UTF-16). It is a similar concept to C's _T() macro for
_TCHAR data, and Win32's TEXT() macro for TCHAR data.
It's not at the moment, and I'm stumped as to why.
Your source file is UTF-8 encoded (right-click on the code editor, File Format,
UTF8). The UTF-8 encoded form of "FÑÙ" (0x46 0xC3 0x91 0xC3 0x99) is being
stored in your EXE file. At runtime, you are passing a UTF-8 encoded char*
to Add(). Since Add() expects a UnicodeString as input, the RTL has to perform
a data conversion. But the RTL does not know that your char* data is UTF-8
encoded. Passing a char* to a UnicodeString converts the data using the
OS default Ansi codepage (or, more accurately, the codepage specified by
the global System::DefaultSystemCodePage variable), which is not UTF-8.
Thus, the conversion produces the wrong result.
Knowing that your source file is UTF-8 encoded, an alternative to the above
code would be to provide an extra runtime cast to ensure the correct conversion
from UTF-8 (instead of Ansi) to UTF-16:
item->SubItems->Add(UTF8String("FÑÙ")); // <-- notice no 'L' prefix
The RTL knows how to properly convert a UTF-8 encoded UTF8String to a UTF-16
encoded UnicodeString.
Originally I thought it was an issue with the conversions, but I
tried the following and it still didn't display correctly.
<snip>
Instead, it displays FÃ'Ù.
"FÃ'Ù" is the UTF-8 encoded form of "FÑÙ" being interpretted as Windows-1252
instead of as UTF-8.
--
Remy Lebeau (TeamB)
Connect with Us