locked
How does Keyboad event handling in Windows Runtime work, how is it different from Win32 and why?

    Question

  • I need to to process keyboard events in TextBox controls (and other UI elements) in Windows RT, but have some problems understanding how it works. I have noticed that the KeyDown event on a TextBox fires before the KeyDown event in the CoreWindow, for example. Why is that?

    I see that the TextBox control have no CharacterReceived event, only the KeyDown/KeyUp events. Why is that? 

    If I mark the KeyDown event in the TextBox as Handled, the CoreWindow will still get KeyDown and (potentially) CharacterReceived events. Why is that?

    If I press Ctrl+M, I get KeyCode==13 in the CharacterReceived event. While this makes sense at some level, it doesn't for this API. An explanation of the thinking behind this would be useful.

    I've been trying to find good resources on how keyboard event handling is dealt with in Windows RT, but haven't found any but lightweight documentation on the topic (eg. which classes exists etc). Any pointers to samples and other resources on this topic would be greatly appreciated.

    I'm asking because I am porting a multi-platform application that have an extensive keyboard handling implementation in place. I do not want to re-write all that for a single new platform. At the most basic level, the existing code performs filtering on text input in textfields, keyboard shortcut handling, etc.



    Friday, March 09, 2012 2:02 PM

Answers

  • Hi Ludvig,

    Can you please explain the scenario you are trying to achieve in more detail so we can make sure to provide a useful answer.

    The CoreWindow class receives the native Win32 keyboard messages. Xaml controls don't have HWNDs and so cannot do so. I believe they get their notifications from CoreWindow and then raise their own events as necessary. Since it's a different event, handling KeyDown on a TextBox doesn't affect the CoreWindow KeyDown.

    I will have to look into how to get the translated characters at a higher level than the CoreWindow. You can do so by handling CharacterReceived and then dispatching it to the focused control, but I expect there is a better way.

    --Rob

    Tuesday, March 13, 2012 1:53 AM
    Owner
  • Hi Ludvig,

    I confirmed that support for character input is only at the CoreWindow level. You will need to handle CharacterReceived and consult the FocusManager to determine which control the input is for. This is essentially what the TextBox is doing internally.

    --Rob

    Thursday, March 15, 2012 12:08 AM
    Owner

All replies

  • Monday, March 12, 2012 9:02 AM
  • I can't see how that class helps in translating a VirtualKey to a Unicode character. Note that handling keyboard shortcuts is only one of many keyboard handling scenarios. I really can't see how the current version of RT would support authoring a custom control that deals with semi-advanced keyboard input, and because this is somewhat baffling, I assume that there's something that I'm missing.
    Monday, March 12, 2012 9:15 AM
  • Hi Ludvig,

    Can you please explain the scenario you are trying to achieve in more detail so we can make sure to provide a useful answer.

    The CoreWindow class receives the native Win32 keyboard messages. Xaml controls don't have HWNDs and so cannot do so. I believe they get their notifications from CoreWindow and then raise their own events as necessary. Since it's a different event, handling KeyDown on a TextBox doesn't affect the CoreWindow KeyDown.

    I will have to look into how to get the translated characters at a higher level than the CoreWindow. You can do so by handling CharacterReceived and then dispatching it to the focused control, but I expect there is a better way.

    --Rob

    Tuesday, March 13, 2012 1:53 AM
    Owner
  • Hi Ludvig,

    I confirmed that support for character input is only at the CoreWindow level. You will need to handle CharacterReceived and consult the FocusManager to determine which control the input is for. This is essentially what the TextBox is doing internally.

    --Rob

    Thursday, March 15, 2012 12:08 AM
    Owner
  • OK, thank you for the answer. Regarding your question about the scenario, here's what we are doing:

    We are building a new user interface engine for Metro to provide the UI for our Standard ERP/CRM products. The UI will be completely Metro-style, while re-using the business logic and workflow of our business, database, reporting, document and network communication engines. Our entire product range is built upon these parts, and we will have our complete range of small, medium and large systems, single- and multiuser, available for Windows 8 as Metro Apps. This include systems for Bookkeeping, Invoicing, Restaurant, Hotel and POS.

     The UI engine for Metro is implemented as a set of custom controls for various tasks, along with use of standard windows runtime controls. As our software systems are strongly focused around data collection and data entry, keyboard handling is an essential part of the business logic that we re-use. Hooking it up requires us to get access to both translated character events and raw keyboard events in our controls.
    Tuesday, March 20, 2012 3:36 PM