Kris wrote:


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.


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.

<snip>

"FÃ'Ù" is the UTF-8 encoded form of "FÑÙ" being interpretted as Windows-1252
instead of as UTF-8.

--
Remy Lebeau (TeamB)

The code originally had the L"...", and that wasn't working. I tried it too originally.

I tried the suggestion of

  TListItem * item = FindListItem(message_id_num);
  if (item == NULL)
  {
    item = m_lst_messages->Items->Add();
    for (int i=1; i<m_lst_messages->Columns->Count; i++)
    {
      item->SubItems->Add(UTF8String("FÑÙ"));
    }
  }

I got something even weirder displaying. I can't reproduce it because I can't copy it, but it's pretty much an F and then what looks like upsidedown question marks and small 1/2's.

Heh...trust me, I know this is weird and that's why I'm absolutely stumped. Everything you're saying makes sense, so something else must be going on and I'm not sure where to look.

https://img42.com/2KrLM. This is a small screenshot of what the output is. Again, it's only in this TListView. It displays fine in the other forms that can be accessed from there.

Any other ideas of what could possibly be causing this? If it's incorrect to begin with, how would I go about looking into that?

The picture has been posted in attachments with the same name as this thread + Attachment:

https://forums.embarcadero.com/thread.jspa?threadID=122027&tstart=0