by Michael S. Kaplan, published on 2008/02/25 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/25/7893424.aspx
One never knows how dumb one was until one gets a little bit smarter. :-)
I'll explain what I mean, how I was reminded of this the other day....
I must admit the question that came to me was a bit more polite that the title, it was actually more like:
Do you know anything about this prop? I checked the Japanese Keyboard and English keyboard with different locale, but it just seems to return the LCID of the corresponding Locale. Please let me know if you know any.
And the underlying question that person had been asked was also more polite:
I would like to check with you if you have information about who is using this particular property and how they use it. It does not have a matching LCTYPE[ in Windows]. Any idea?
This property (in both CultureInfo.KeyboardLayoutId and CultureAndRegionInfoBuilder.KeyboardLayoutId) was kind of my idea because of an LCID dependency that the InputLanguage class has in its InputLanguage.FromCulture method.
Now in fairness that dependency was only there because the developers were looking at the Win32 GetKeyboardLayoutList function and seeing it was the only way to enumerate loaded keyboards (which is basically all that FromCulture was trying to do (map loaded input languages with the passed in CultureInfo).
But now with custom culture, the CultureInfo.LCID would not be a useful thing to compare; it would alway fail.
So this KeyboardLayoutId was added as a stopgap -- so there would be a way to specify the keyboard to load.
Anyway, I am not taking the credit for this idea, more like I am taking the blame. Because the view from this CLR-specific problem was too narrow!
Working with folks later on MSKLC, the solution mentioned in Getting the language of an LCID-less keyboard and then documented in Getting the language (and more!) of an LCID-less keyboard with the apocrypha at MSKLC keyboard layout names in your own language became an obvious way to not only support custom languages to do along with custom keyboards, but a way for someone to query exactly what the custom locale name might be!
Of course this other property will always be there unfortunately, but now future versions have a method they can look into using to let them shed the LCID and now KeyboardLayoutId dependency!
I suppose there is a lesson here -- it is important to think about the whole problem rather than just the piece in front of you, if you want to come up with the best solution in the long run....
This post brought to you by ᕓ (U+1553, a.k.a. CANADIAN SYLLABICS FE)
BigScary on 28 Oct 2010 10:14 AM:
So, what is it then? I'm looking for the answer in your post, but I don't see it. I'm writing a test wherein I want to create a custom culture with an invalid keyboard layout (is zero always invalid?), to confirm that my other API, which is supposed to switch to a desired keyboard layout, appropriately throws an ArgumentException when the desired keyboard layout is invalid or otherwise unavailable.
Michael S. Kaplan on 28 Oct 2010 7:13 PM:
Not sure what you are asking in this case? One should always set the property to something....
referenced by