by Michael S. Kaplan, published on 2008/05/23 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/05/23/8537281.aspx
Joost van Doorn asks (via the Contact link):
Hello Michael,
Since your name appears in a lot of MSDN questions on International application programming, I ask my question directly to you. I'm working on an application that supports various languages. It is a C++ (Borland Builder) application. One of the aspects involved is the addition of extra keyboard. I use the API function LoadKeyboardLayout and I can add, for example, French with a french keyboard. However our PCs are always sold with a US-International keyboard. So I would like to, for example, French with a US-Internal keyboard.
I have tried two approaches:
1. Use the LoadKeyboardLayout function: This does not work. I always get the return value "04090409" (I run XP - English).
2. Changing the registry: Changing the HKCU\Leyboard layout properties is no problem but getting the new settings active - without rebooting - is a problem.
I have posted some question into the MSDN newsgroups but up to now no answers. This is really important to me so could you please help me.
Best regards,
The registry mucking is a truly bad idea -- I highly recommend against that approach.
It is true that LoadKeyboardLayout won't work here -- it only works for loading a specific keyboard when the language it is to be under matches. Having the LANGID in the LOWORD of the keyboard's KLID not match the language the keyboard is under? LoadKeyboardLayout isn't able to help. :-(
Though as I mentioned in Cutting the cord, revisited -- and documenting how to get the job done!, there is now a documented method for getting this done: the InstallLayoutOrTip function in input.dll. This is new in Vista and supports these "mixed language" scenarios.
Though some have read Not exactly reverse engineering... and been intrigued by those [NONAME] exports, all I can say is that this new Vista function is not one of them -- so that isn't the most productive line to pursue. For earlier versions there is really just one answer that is documented/supported - the InputLocale keyword in an intl.cpl unattend call describead in KB289125 (mentioned in blogs like this one, previously) -- note that the first value is LANGID of the language for the Language Bar, and the second is for the KLID representing the keyboard.
This post brought to you by ಊ (U+0c8a, aka KANNADA LETTER UU)
Joostmsdn on 27 May 2008 4:20 AM:
Hello Michael,
Thanks for providing the input. I have now solved the problem.
Best regards,
Joost