[wxMSW] wxPropertyrGrid button text (drop down arrow) is corrupted (small patch included) (Issue #23095)
Eran Ifrah
The button looks corrupted, this is caused because the text used for the button is Unicode (the unicode symbol for ...)
Such symbols should not be translated, so wrapping them with wxT(...) fixes the issue
this one-liner patch fixes this:
diff --git a/src/propgrid/editors.cpp b/src/propgrid/editors.cpp index 8e2205a3af..b06e530174 100644 --- a/src/propgrid/editors.cpp +++ b/src/propgrid/editors.cpp @@ -1979,7 +1979,7 @@ wxWindow* wxPropertyGrid::GenerateEditorButton( const wxPoint& pos, const wxSize wxPGProperty* selected = GetSelection(); wxASSERT(selected); - const wxString label("\u2026"); // "Horizontal ellipsis" character + const wxString label(wxT("\u2026")); // "Horizontal ellipsis" character int dim = sz.y + 2*wxPG_BUTTON_BORDER_WIDTH;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Thanks, this should indeed be either L"\u2026" or FromUTF8("\xE2\x80\xA6") if you prefer. I'll let @a-wi choose...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Eran Ifrah
IMO, the former is more human readable, but - its not up to me ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
The advantage of using FromUTF8() is that we could actually use the real … character too in the sources if we could guarantee that they always use UTF-8 encoding. Unfortunately I don't know if we can do it for wx -- for my own code I do it like this but I have more control on how it's compiled.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
AW
@eranif It looks you see the issue in wxMSW port. What compiler/custom settings do you use? With VS 2022 (wxUSE_STL=1, wxUSE_STD_CONTAINERS=1) ellipsis character looks fine without L (wxT) prefix in the string representation. It also looks fine without any prefix under wxGTK with g++ 10.2.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Using \u inside a narrow string encodes the character in the compiler character set (almost invariably, but not necessarily, UTF-8 nowadays). Constructing wxString from narrow string uses the current locale encoding which will again typically, but not always, be UTF-8. So it's not surprising that it works sometimes. It is, however, perfectly possible that it doesn't work in other cases and we should really use either L or UTF-8 for it explicitly.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
AW
Closed #23095 as completed via 7cd5826.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.