by Michael S. Kaplan, published on 2008/03/02 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/03/02/7934470.aspx
Please read the disclaimer; content not approved by Microsoft!
And it has had some effect (though in fairness that would most likely be because people were talking about the KeyboardLayoutId anyway, as the post was clearly indicating!).
One important thing to be careful about is to make sure (if you're one of those people!) that the same mistake is not made that was made in the original KeyboardLayoutId property, which is to not look at the whole problem and come up with a comprehensive solution, but I have faith that everyone will do The Right Thing™, eventually. :-)
In this case, The Right Thing™ definitely involves a whole bunch of steps, like
Now obviously one could skip steps.
One could skip step #1 (after all the documentation has kind of been inadequate since .NET 2.0 came out and the KeyboardLayoutId was first added!).
Or one could skip step #2 (after all the current implementation has been there and does work with the GetKeyboardLayoutList function that exists today in Win32 without requiring extra looking at the registry!).
Or one could skip step #3 (after all if it is poorly documented then you do not lose much by not doing anything else with a property that one does not explain very well!).
Or one could move boldly forward with some but not all of these steps.
Or one could do the steps out of order (putting the cart before the horse, as it were).
Though I like the phrase putting the computer in front of the keyboard better, since we don't really have nearly as much in the way of either carts or horses these days, which makes the phrase less viscerally useful.
But everyone who uses a computer with a keyboard knows or can potentially visualize what the net effect would be of hiding the keyboard behind the computer -- it would make people unable to type!
It is way to early to know what will happen, or what people will do. For now, I have made my own meager contribution to #1, and I guess that's a part of a first step. And my post shows up as #3 on a Google search of KeyboardLayoutId and a Live Search of KeyboardLayoutId, so people might find it. Now unfortunately it is #35 in an MSDN Search (powered by Live Search) but the rest of the entries are on the property, plus a couple of forum questions with people not knowing what the property does like this one from May of 2006 so I suppose I should be happy at the unpolluted nature of the pure Live Search results, which don't have to think it artificial terms about the importance of MSDN blogs (whose recent posts are less relevant than the also-user-community-driven forum posts?).
In the end, I am really not that worried -- because The Right Thing™ will end up happening, for some or most values of right. But it is fun as people try to figure out how to hide that keyboard, primarily because there is no way to write mail or specs about the situation when it is in fact hidden behind the computer. The mental picture keeps me amused. :-)
1 - As I point out here, this blog does not constitute official documentation or company policy.
2 - What that might be is I think unclear at the moment, though I daresay it mightn't always be that way....
3 - When I say older, I mean "future Older", by which I mean after the problems in #2 are solved, coming up with a good fallback purpose for KeyboardLayoutId based on the fact that existing custom locales/cultures might have it set.
This blog brought to you by ™ (U+2122, aka TRADE MARK SIGN)