by Michael S. Kaplan, published on 2008/03/06 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/03/06/8026142.aspx
Please read the disclaimer; content not approved by Microsoft!
The other day I heard from programmer Scawen Roberts via the Contact link over a couple of days. His question was:
Thank you for your "random stuff of dubious value" which has helped me here and there recently as I've been updating LFS to support Chinese, Japanese and Korean. I have found the IMM / IME documentation and internet references a bit more sparse than most things but eventually managed to get over most hurdles.
It's nearly there but a tester in China has come across one Vista issue that I cannot find the answer to. It's about showing the name of the active input method (important as LFS usually runs in full screen mode). At the moment I can show the IME name in XP but not in Vista.
As you know, when the user presses CTRL+SHIFT (having pressed ALT+SHIFT to select Simplified Chinese) the active input method is changed (US Keyboard / ZhengMa / Microsoft PinYin etc...).
In XP I am able to retrieve the name of the active input method using a little code something like this :
Then I look up the k_layout entry with a registry lookup in SYSTEM\CurrentControlSet\Control\Keyboard Layouts\[k_layout] and Query the value "Layout Text".
This works great in Windows XP, LFS then displays the retrieved value in its text entry dialog and the user can see the active input method.
The problem : In Vista, the Simplified Chinese input methods have been unified into a single IME and the GetKeyboardLayoutName function always returns the same value regardless of which input method the user has selected. So the registry lookup always returns "Chinese (Simplified) - US Keyboard" regardless of which input method is selected.
All I want to do is display "ZhengMa / Pinyin / NeiMa" or whatever when it is selected.
Well... I hope that is an interesting problem in some way and perhaps you'll be able to point me in the right direction.
Thanks for your help!
And then the message a few days later:
Just following up an email I sent to you the other day, I've made a post on our forum asking any of our community programmers if any of them might just know how to solve this issue of how to display the name of the active input method when using the new "unified" Chinese IME in Windows Vista. I wrote a tiny Windows program which demonstrates the issue by working correctly in XP but not in Vista.
Anyway any help would be much appreciated, or if you could let me know who I should contact. I'm starting to get the feeling this might have been a design oversight in Vista.
Technically, it might be worth it to look into the information in Getting the real (localized) name of the keyboard rather than using the Layout Text registry value directly, but that won't help for this problem either so I'll just leave that mention in passing for Scawen to consider. :-)
Plus I feel like that blog post is one that I should get more mileage out of, since to this day it has remained the most popular spam target for reasons still never identified!
But to answer Scawen's question, this is not an oversight in Vista, no.
Though it is a part of the design change to move fully into the world of the Text Services Framework.
As I explained in Cutting the cord while someone else is shoring it up, with the exception of the three input methods that Office 97 "adds back" to that legacy list for programs that do not use TSF, the IMEs that have moved on have in fact moved on and the only way to query them for information is through the interfaces of the Test Services Framework.
In this particular case the IEnumTfLanguageProfiles interface holds the most hope, I suppose, which gets you a bunch of TF_LANGUAGEPROFILE structs.
From there? I don't really know -- something with
I suppose, to query information from the text service itself to get the actual name somehow?
Maybe the ITfInputProcessorProfiles interface is the one with the information?
It's ITfInputProcessorProfiles::GetLanguageProfileDescription method looks the most hopeful, especially since it takes an rclsid, a langid, and a guidProfile, and returns a "description string" as a BSTR.
Yes, I know -- a TSF sample would still be a really good idea for this kind of thing. It is just difficult to start jumping in here, I think. Not to mention how 90's COM interfaces feel -- almost like a foreign language that one spoke in one's youth? :-)
The closest I have seen for this kind of thing is in an article from last year, entitled Vista 與輸入法程式介面 (There's no English translation of the article, and my Mandarin is far less than stellar; the online translation sites suggest something like "Vista programming interface and input method" and that sound reasonable enough).
The code there includes perhaps enough hints to get one started even if you too don't speak the language? :-)
The irony involved with answering the question to a developer from a software company helping their customer in China with this article is not completely lost on me, but let's ignore that and focus on the potential coolness of the solution!
This blog brought to you by པ (U+0f54, aka TIBETAN LETTER PA)
# Arthur Hsu on 21 May 2008 3:10 AM:
The article entitled "Vista 與輸入法程式介面" should be translated as "How to programatically select input methods under Vista"
The code basically provides C# wrapper for .Net 1.0/2.0/3.0. I've heard that .Net 3.5 provide equivalent support in CLR directly, but I did not really test it.
BTW, the sample code links for TSF on MSDN (links provided in this page are all dead. Did you know where can we find them?
I have inquired of the PSDK owners and they are looking into getting the dead link issue fixed... - Michael
june on 15 Aug 2011 7:55 PM:
hi,i am chinese.
go to newer or older post, or back to index or month or day