Details
-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
None
-
Operating System: ReactOS
Platform: x86 Hardware
Description
1- CAPS-LOCK does not send WM_KEYUP & WM_KEYDOWN.
You must press an release that key another time for receiving the messages.
If a different key is pressed in the meanwhile, you must press CAPS-LOCK again for two times before receiving the event.
Scenario:
CAPS-LOCK pressed (no message)
CAPS-LOCK released (no message)
CAPS-LOCK pressed WM_KEYDOWN
CAPS-LOCK released WM_KEYUP
CAPS-LOCK pressed WM_KEYDOWN
CAPS-LOCK released WM_KEYUP
ESC pressed WM_KEYDOWN
ESC released WM_KEYUP
CAPS-LOCK pressed (no message)
CAPS-LOCK released (no message)
CAPS-LOCK pressed WM_KEYDOWN
CAPS-LOCK released WM_KEYUP
2- Pressing F10 a second time does not exit from menu loop.
Same thing happens to the left and right ALT keys.
3- Apparently, the right CTRL stays always pressed.
When releasing the key, it does not send the WM_KEYUP message, but it sends it when you press the button again.
Scenario:
RIGHT CTRL pressed WM_KEYDOWN
RIGHT CTRL released (no message)
RIGHT CTRL pressed WM_KEYUP + WM_KEYDOWN
RIGHT CTRL released (no message)
RIGHT CTRL pressed WM_KEYUP + WM_KEYDOWN
....
4- When pressing the '/' key of the numeric pad, the WM_CHAR message is sent after WM_KEYDOWN and not after WM_KEYUP.
5- ENTER key of numeric pad: the WM_KEYUP message is never sent.
6- The PrintScrn key should send only WM_KEYUP. Instead it seems to work like the right CTRL key.
7- Common to all keys: when using autorepeat of keys, on Windows it sends:
WM_KEYDOWN
WM_CHAR
WM_KEYDOWN
WM_CHAR
...
WM_KEYDOWN
WM_CHAR
WM_KEYUP
ReactOS also sends the WM_KEYUP message:
WM_KEYDOWN
WM_CHAR
WM_KEYUP
WM_KEYDOWN
WM_CHAR
WM_KEYUP
...
WM_KEYDOWN
WM_CHAR
WM_KEYUP
Attached test program is useful for verifing the described behaviour.
Sincerely,
Carlo Bramini.
Attachments
Issue Links
- blocks
-
CORE-5619 METABUG: Keyboard problems
- Resolved