locked
Is there an easy way of getting every key press whether shifted or not ?

    Question

  • I have used the keydown event to capture key presses but lots of keys are missing.

    I figured out how to capture caps lock and change lower case a-z to upper case A-Z.

    But I was still missing punctuation.

    I found "characterreceived" function which gives me some punctuation but not all.

    So I now have 2 keyboard functions, keydown and character received.

    I use keydown for virtual key detection and characterreceived for the rest.

    But I am still missing a few key presses.

    Is there anyway to capture all key presses like I could in WPF ?


    n.Wright

    Sunday, October 20, 2013 2:17 AM

Answers

  • CharacterReceived is the appropriate event to get the actual characters. Can you give more information about where it is failing for you? CharacterReceived should receive all characters.

    KeyDown and KeyUp give keys, not characters, and there is no good way to convert these to characters. To do so properly requires significant knowledge about the specific keyboard used.

    --Rob

    Sunday, October 20, 2013 3:30 AM
    Owner
  • CharacterReceived should get the "#" character (0x23) and does in my quick test.

    Is there a chance that something elsewhere in the app is intercepting it?

    --Rob

    I am getting code 163 for the # key. I am using a UK keyboard so maybe that's why it is different.

    In the UK shift 3 is the pound sign not #.

    If I convert any 163's to 35's then the display works fine.

    I am using the ASCII (Teletext) character set in my program and these codes are between 0 and 127.

    This means the 163 was never being displayed as it was being trapped out.


    n.Wright

    Tuesday, October 22, 2013 2:04 AM

All replies

  • CharacterReceived is the appropriate event to get the actual characters. Can you give more information about where it is failing for you? CharacterReceived should receive all characters.

    KeyDown and KeyUp give keys, not characters, and there is no good way to convert these to characters. To do so properly requires significant knowledge about the specific keyboard used.

    --Rob

    Sunday, October 20, 2013 3:30 AM
    Owner
  • I checked it again to day and the only one missing is shift 3 which is the pounds sign.

    n.Wright

    Sunday, October 20, 2013 2:42 PM
  • CharacterReceived should get the "#" character (0x23) and does in my quick test.

    Is there a chance that something elsewhere in the app is intercepting it?

    --Rob

    Tuesday, October 22, 2013 12:32 AM
    Owner
  • CharacterReceived should get the "#" character (0x23) and does in my quick test.

    Is there a chance that something elsewhere in the app is intercepting it?

    --Rob

    I am getting code 163 for the # key. I am using a UK keyboard so maybe that's why it is different.

    In the UK shift 3 is the pound sign not #.

    If I convert any 163's to 35's then the display works fine.

    I am using the ASCII (Teletext) character set in my program and these codes are between 0 and 127.

    This means the 163 was never being displayed as it was being trapped out.


    n.Wright

    Tuesday, October 22, 2013 2:04 AM
  • That makes sense. Thanks for letting us know what was going wrong, and I'm glad you have it working.

    Part of the confusion is that you said "pound sign" rather than "£". The "#" is also called a pound sign and is Shift-3 on typical US and Canadian keyboards. Isn't global language fun? :)

    --Rob

    Tuesday, October 22, 2013 2:15 AM
    Owner
  • Code page isn't relevant here. Windows Store apps are all Unicode.

    Having a renderer which displays only 7-bit characters will have globalization problems (such as this one) where non basic-latin characters won't render without a custom mapping (like forcing 163 -> 35), but since the Unicode code points are consistent the mapping can also be consistent. MBCS would be much more complex and require code pages to map the same char value to multiple meanings.

    --Rob

    Wednesday, October 23, 2013 1:37 AM
    Owner