by Michael S. Kaplan, published on 2011/04/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/04/04/10149502.aspx
It was a while back that Gisle asked in the Suggestion Box:
Hi Michael,
I have enjoyed your blog for a long time, learned a lot and also had the pleasure of attending some of your talks at Unicode conferences.
I work for a company that produces a compiler and a runtime. In the past we have implemented support for the UXTheme, for various reasons we have not yet been able to make the system fully Unicode. The UXTheme implementation have however worked well, until recently when a user with special demands started using it. The special thing about this user is that they alter the application locale to allow input from other locales during execution. Like for instance going from English to Greek.
What we then experienced, was that when our non Unicode application for instance swapped to Greek on a system with the default non Unicode locale set to English, we were only getting substitute characters (?).
I assume this is because the UXTheme controls are all native Unicode and in a response to the WM_GETTEXT (also tried with GetWindowTextW), it is translating it to the default system locale (I am guessing this as I tried to change the system locale to Greek and it then worked).
So, I guess you figured out where I am heading. Is there a way to overrule the UXTheme default translation from CP_ACP to a specific locale programmatically?
I have searched your blog to see if I missed something, but either I am not searching for the right thing, or is it just not there.
Hoping for a suggestion.
Keep up the good work, you are a great resource for the rest of us!
I wish I had a better answer, but there is unfortunately no Visual Styles (UXTheme) way to globally change the code page used to do conversions to and from Unicode.
UXTheme is pretty much a "Unicode or CP_ACP" technology....
Though there is a habit of thread locale type behavior you can look into here -- you may get lucky trying that? They don't document it as working that way but it has been quite common in the past in some places, so it may work -- it's hard to say. Plus they might break it later if it works sometimeas.
This functionality even breaks some of the functionality that worked on Windows 95/98/Me -- the functionality I discussed in Double Secret ANSI, part 1 (Somewhere between ANSI and Unicode). In its own way that is unfortunate since that is exactly the feature you're looking for.
Though given how much Microsoft broke that later (ref: Double Secret ANSI, part 2 (the brokenest one yet, sorry 'bout that!)), I guess it isn't really something that it would have made too much sense to depend on. :-(
So solutions here are (more or less) unavailable.
Now with all that said, some basic testing with App Locale and it seems to work. So I suppose as workarounds go that isn't all bad.
Though it is still pretty limited since you stay limited to one code page at a time.
In the long run, the only way to support the scenario is to start supporting Unicode.
Sorry, Gisle. :-(