locked
Keyboard control codes in character based console mode programs running under Windows 8 Release Preview (64 bit) RRS feed

  • Question

  • In Windows 8 Release Preview accessing and working with keyboard control codes (e.g. Ctrl_A, F1, Esc, Cursor left, right, up, down, etc.) in character based console mode programs are handled differently than in all prior Windows versions.  Problem is that those control codes are echoed to the screen and are not executed/interpreted immediately. For example a test program waits for a keystroke (press any key to continue) and will just return and output the key code of the last key pressed (e.g. something like wait; output lastkey()  ... while lastkey() is a simple function returning the value behind the last pressed key). If the last key pressed is Ctrl_a - which has a return value of 320 - the screen shows "^A" and an additional pressing of the enter key is required to generate the expected output of "320". The real problem is that those control codes are often used to drive (old) character based applications, e. g. moving in menues or editing text, browsing forward or backwards through database records displayed on screen or displays help screens, etc. All of those programs have been running fine in Windows 7, XP, etc. within a command prompt or a Powershell window.  Maybe Microsoft can reproduce/solve these kind of problems before the final release of Windows 8. To test I used GURU version 7.1, a 32 bit Expert system and relational database development tool of former MDBS Inc. (company does not exist anymore). Anything is still working fine except keyboard control and mapping of key codes. However, other (old) character based applications may suffer from this problems, too.

    Best regards,

    Helmut    

    Sunday, June 24, 2012 3:21 PM

Answers

  • Hi all,

    I found a workaround myself: Sending first a "Ctrl_z + <enter>" from keyboard to the application seems to clear an internal buffer or so and after that proper keyboard mapping, etc. is performed and everything works fine. While sending this key combination the initial cursor position may advance to the next line but it seems to work so far. Maybe there is still something wrong with keyboard or keyboard buffer handling Microsoft should have a look into. Thanks.

    Helmut

    Sunday, June 24, 2012 4:58 PM

All replies

  • Hi all,

    I found a workaround myself: Sending first a "Ctrl_z + <enter>" from keyboard to the application seems to clear an internal buffer or so and after that proper keyboard mapping, etc. is performed and everything works fine. While sending this key combination the initial cursor position may advance to the next line but it seems to work so far. Maybe there is still something wrong with keyboard or keyboard buffer handling Microsoft should have a look into. Thanks.

    Helmut

    Sunday, June 24, 2012 4:58 PM
  • Thanks for sharing the workaround.

    Niki Han

    TechNet Community Support

    Friday, June 29, 2012 7:51 AM
    Moderator