Re: [lmi] Unexpected character in file history

[Vadim Zeitlin]

On Tue, 14 Jun 2016 21:38:40 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-14 20:39, Vadim Zeitlin wrote:
GC> > On Mon, 13 Jun 2016 13:39:29 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> When I pull down the "File" menu, history now looks like this:
GC> > GC>   1 □quote.cns
GC> > GC>   2 □quote2.cns
GC> > GC> I'm not sure the square character is unicode "WHITE SQUARE"; it could
GC> > GC> be something else with a similar appearance. No such character is
GC> > GC> shown with last month's release; could this be a wx regression?
GC> > 
GC> >  Unfortunately I'm not able to reproduce this at all, so I can't test the
GC> > fix neither :-(
GC> 
GC> If you've already developed a speculative fix, I could test it.

 Here is one possible fix, disabling this character under XP entirely:

---------------------------------- >8 --------------------------------------
diff --git a/src/common/filehistorycmn.cpp b/src/common/filehistorycmn.cpp
index c2ca5c5..7e1894b 100644
--- a/src/common/filehistorycmn.cpp
+++ b/src/common/filehistorycmn.cpp
@@ -30,6 +30,10 @@
 #include "wx/confbase.h"
 #include "wx/filename.h"
 
+#ifdef __WXMSW__
+    #include "wx/utils.h"
+#endif
+
 // ============================================================================
 // implementation
 // ============================================================================
@@ -51,11 +55,17 @@ wxString GetMRUEntryLabel(int n, const wxString& path)
     pathInMenu.Replace("&", "&&");
 
 #ifdef __WXMSW__
-    // absolute paths always start with Latin characters even in RTL
-    // environments and should therefore be rendered as LTR text (possibly with
-    // RTL chunks in it). Ensure this on Windows by prepending
-    // LEFT-TO-RIGHT EMBEDDING (other platforms detect this automatically)
-    pathInMenu.insert(0, wchar_t(0x202a));
+    // The Unicode character below is not rendered correctly by XP sometimes,
+    // apparently, even if it seems to work in other cases, so avoid using it
+    // under this obsolete OS.
+    if ( wxCheckOsVersion(6 /* Vista */) )
+    {
+        // absolute paths always start with Latin characters even in RTL
+        // environments and should therefore be rendered as LTR text (possibly 
with
+        // RTL chunks in it). Ensure this on Windows by prepending
+        // LEFT-TO-RIGHT EMBEDDING (other platforms detect this automatically)
+        pathInMenu.insert(0, wchar_t(0x202a));
+    }
 #endif
 
     return wxString::Format("&%d %s", n + 1, pathInMenu);
---------------------------------- >8 --------------------------------------

I also thought about testing whether wxUxThemeEngine::GetIfActive() returns
something non-null (this requires including "wx/msw/uxtheme.h") and disable
this behaviour only when not using themes, but so far I have no reason to
believe it has anything to do with themes.

GC> However, would it even be appropriate to change wx trunk for this?
GC> Perhaps commit/e5e92c9... really was a useful improvement for msw-xp
GC> users of right-to-left alphabets.

 Yes, it fixes a real problem when using Hebrew version of MSW.

GC> And perhaps the reason why this happens--on my machine only--is that
GC> I'm running in a VM with a paravirtual graphics driver.

 I don't think so. My last hope is that you might be running a different
and earlier XP version than me: do you have XP SP3 (which is the XP version
by default because anything earlier is just too hopelessly broken)? If you
do, changing the OS version check above to "5,1,3" should also fix the
problem for you while leaving the workaround enabled for all the rest of XP
users. If you don't, I really have no idea :-(

GC> You can't reproduce it, our end users won't see it, and it's not an
GC> actual problem for me, so maybe we should just drop it.

 I will if the guess above is not correct.

 Thanks in advance for your testing,
VZ