by Michael S. Kaplan, published on 2007/09/27 03:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/27/5141426.aspx
Via the Contact link, 'Fret' comments:
I've been debugging why my app doesn't accept 0x0218 and 0x021B characters from the keyboard on Vista.
You say it's not a windows bug. What I'm seeing in the debugger is that first I get a WM_KEYDOWN, which I translate to 0x0218 via ToUnicode and then after that I get a WM_CHAR, and the wParam is 0x003f, where is where our question mark comes from. So I'm thinking that windows is trying to convert the WM_KEYDOWN into a WM_CHAR and failing because it's not in the ANSI codepage? Applications that process just the WM_KEYDOWN work properly, but if you happen to like processing WM_CHAR's then your out of luck.
At least thats what I think is going on. I could be wrong.
I'm seriously considering rewriting my apps so they don't use WM_CHAR at all. But maybe that is overkill and there are less drastic fixes available.
Regards
No need to fret, er... Fret!
Of course it isn't a Windows bug, and you definitely do not have to stop processing WM_CHAR notifications and move processing to WM_KEYDOWN.
All you have to do is compile your applications to use UNICODE/_UNICODE, and then you won't see everything being converted out of Unicode and into a code missing the characters you want to use.
Now if you really don't want the applications to support Unicode then you are out of luck a little and have to go to those extreme measures (I say extreme since you either have to define the mappings yourself or you have to still call a bunch of Unicode keyboarding functions within your non-Unicode applications to be able to query what characters the keystrokes map to -- a painful fallback plan, all things considered....
It is one of the reasons that the issues in Not everyone does the right thing for Romanian are so painful and why the moves in usage from
have problems for so many applications that were never moved to Unicode since people figured they never had to make the move....
So moving the fonts and the keyboards to use the newer characters due to the linguistic pressure but not putting that same pressure on the applications is bound to lead us to where we are now.
It is time to fix those applications!
In the end, people in Romania are as unlikely to speak fluent question mark (which is that handy 0x3F that Fret is seeing) as anyone else in the world,which is why it is unfortunate that there are so many common applications out there that still aren't doing the right thing in regard to Unicode....
This post brought to you by ? (U+003f, a.k.a. QUESTION MARK)
# Aaron Ballman on 27 Sep 2007 11:26 AM:
I ran into this issue myself (back when our application had to have a single binary to support Windows 98 and up), and the issue turned out to be the fact we were using Unicode in most places (such as defining the window and within the WndProc), with an accidental ANSI call to GetMessage/DispatchMethod in our mesage pump.
I am so happy we changed our requirements to Win2k and up so this sort of weirdness doesn't happen anymore! ;-)
# Mihai on 27 Sep 2007 1:48 PM:
Although Windows might try and convert the WM_CHAR Unicode to ANSI using best fit. Then U+0219 would be converted to 0xBA cp1250 (U+015F).
But well ...
Sometime I wish that some change of change that requires Unicode would badly break English functionality :-)
Everybody will be unhappy for a while, move to Unicode, but in the end we will be in a better state.
Just be patient, everybody will be Unicode sooner or later (right after U.S. finally adopts the metric system :-)
# Michael S. Kaplan on 27 Sep 2007 1:54 PM:
The only way to do that would be to change the code page to add new best fit mappings, which we cannot do for stability reasons....
# Aaron Ballman on 27 Sep 2007 2:07 PM:
"Just be patient, everybody will be Unicode sooner or later (right after U.S. finally adopts the metric system :-)"
Don't forget about converting everyone in Liberia and Myanmar too. ;-)