Not eliding correctly on QListView in Windows (OS)-CodePudding

I work with both operation systems (windows and linux) and in linux (image 1) ElideRight is working well but in windows (image 2) is not working well. (...) supposed to be "a" instead.

I use the code below for "Eliding".

Also you need to know, this is happening in QListView.

ui->geometry_list->setTextElideMode(Qt::ElideRight);

CodePudding user response：

I tried to reproduce OPs issue with the following

There are in fact no ellipses. However… Please, note the horizontal scrollbar.

So, I added one line to switch the scrollbar off:

  qLst.setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);

Output:

So, this is working in Windows in general. (I would have been surprised if not.)

The claim of OP that an à is shown instead of ellipses made me a bit suspicious. This could be a sign for encoding problems. However, as Qt is using Unicode in QString such issues are unlikely. (I never experienced such issues while developing with Qt in Windows in daily business.)

Just, out of curiosity, I compared the Windows 1252 encoding of à (224 = 0xE0) with the Unicode of ellipses (U 2026), in UTF-8 encoding: e2 80 a6, in UTF-16 encoding: 26 20 (LE) or 20 26 (BE).

This doesn't look like a mis-interpreted encoding – at least, no obvious. However, to sort this out, OP had to provide a little bit more info like e.g. an MCVE which makes the issue reproducible. (Thus, OP could use my MCVE whether it reproduces the issue on OPs platform.)

I suspect that this an encoding problem but happening while the item texts are stored in QStrings. It's just the list view which exposes the broken item text. Thereby, consider that it's very likely that strings retrieved in Linux are already in UTF-8 encoding. If a QString is assigned from a std::string, UTF-8 encoding is assumed as well. (QString::fromStdString()).

This is different in Windows where the internal encoding is UTF-16 but these ANSI flavors of system functions (with different meanings of character values depending on current code page) are still available (which are always good for any encoding damage).