Why is the Silverlight Key enum missing common characters like comma and period?


Short version is, the keys we left out are harder than you might think to support, and they weren’t necessary for the scenarios we focused on (tabbing around forms, writing common controls, accelerated keys, etc.).

 

The longer version requires a little background on how keyboards differ across various languages, especially on Mac. Different languages have different keyboards — eg, in English, the comma and period are on separate keys, but some European keyboards put them on the same key.  Windows has an abstraction called the virtual key code (eg, OemPeriod), which is what the KeyDown event returns.  Unfortunately Mac doesn’t have a concept of virtual key — they have keyboard-dependent scan codes and they have Unicode, but they don’t have the thing that sits in between on Windows called virtual keys.  For alphanumeric and a couple other common keys, Mac uses the same scan code for all languages, but for the rest of the keys they make no promises.  So if Silverlight wanted to support some of these keys on Mac, we would need to create our own mapping layer — eg. for Russian, scan code 1373 => OemPeriod, for Japanese scan code 528 => OemPeriod…  It could be done, but didn’t seem like the best use of resources, so we handled the most common cases and give you PlatformKeyCode for the rest.


Comments (5)

  1. I appreciate decisions like this. Thanks for posting about it.

  2. Mike says:

    Thanks for posting this.  Good place to send whiners on the forums when they complain about Silverlight "missing" features

  3. Nice. Just an idea: you can provide a utility library with helpful extension methods that do the heavy lifting as part of the SDK 🙂

  4. Greg says:

    Although this makes sense from a programmers "we can’t deliver everything at once" perspective… I will say this:  This type of limited implementation sucks and is a total drain on programmers time in the real world.  What you should have done is for real characters pass the ‘character’ as an additional event arg. (and null for non-displayable characters) .. this would have prevented the need for any further changes going forward.