[Bug 39] New - PrgWin95: Wrong message sequence for keyboard auto-repeat
wine-bugs at winehq.com
wine-bugs at winehq.com
Sat May 25 17:17:26 CDT 2002
http://bugs.winehq.com/show_bug.cgi?id=39
*** shadow/39 Sat May 25 17:17:26 2002
--- shadow/39.tmp.365 Sat May 25 17:17:26 2002
***************
*** 0 ****
--- 1,68 ----
+ +============================================================================+
+ | PrgWin95: Wrong message sequence for keyboard auto-repeat |
+ +----------------------------------------------------------------------------+
+ | Bug #: 39 Product: Wine |
+ | Status: NEW Version: unspecified |
+ | Resolution: Platform: |
+ | Severity: normal OS/Version: All |
+ | Priority: P1 Component: wine-kernel |
+ +----------------------------------------------------------------------------+
+ | Assigned To: wine-bugs at winehq.com |
+ | Reported By: fgouget at codeweavers.com |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | Milestone: TargetMilestone: --- |
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ The message sequence that Wine generates when a key is in auto-repeat mode is
+ incorrect.
+
+ In Windows one gets a series of WM_KEYDOWN messages. The first one has the
+ 'previous state' bit (30th of LPARAM) set to 0, and all those that come after
+ have it set to 1. Then when the key is released the application gets a single
+ WM_KEYUP message.
+
+ In Wine the application receives a succession of WM_KEYDOWN and WM_KEYUP
+ messages instead. Note that this description is valid for a key like the down
+ arrow key.
+
+ If the key generates characters, 'a' for instance, then these messages streams
+ are interspersed with WM_CHAR messages. But the principle remains the same.
+
+ This problem is best illustrated by a couple of programs from programming books:
+ - the keylook example of the chapter 5 of the 'Programming Windows 95' Petzold
+ - the KeyView1 example of the chapter 6 of the 'Programming Windows 98' Petzold
+ - the VirtualKey example of the chapter 3 of 'Programming Windows 95 with MFC'
+
+ See also:
+ http://fgouget.free.fr/wine/PrgWin95/Chap5.shtml#keylook
+ http://fgouget.free.fr/wine/PrgWin98/Chap6.shtml#KeyView1
+ http://fgouget.free.fr/wine/PrgMFC/Chap3.shtml#VisualKB
+
+ ------- Additional Comments From dtimoshkov at codeweavers.com 2000-11-03 03:33 -------
+ The root of this problem lies in the way X server sends keyboard events.
+ X *always* generates Down/Up events for the single key press. It could
+ be seeing with the xev tool. I don't know a way yet how to work around it.
+
+ One ugly hack could be to delay sending WM_KEYUP message, but for what
+ amount of time: until next key press, 1 ms, next X event, ...?
+
+ ------- Additional Comments From fgouget at codeweavers.com 2000-11-12 15:01 -------
+
+ Disclaimer: I don't know anything about the way X handles the keyboard.
+
+ But I just got an idea. In most systems you can receive an event saying that
+ such and such key has been pressed/released, but you can also query whether a
+ given key is up or down.
+ When we receive the KeyUp event, would it be possible to query X to determine
+ if the key is really up or if it is pressed? If it is still pressed, then we
+ would ignore the KeyUp event, mark the key as pressed internally, and on the
+ next KeyDown event we would send a VM_KEYDOWN with the bit 30 set to 1.
+ Of course doing so probably won't be very simple: I guess there will be nasty
+ key mapping issues, it will introduce a (small) delay if the X server is
+ remote... But the point is moot if we cannot query the state of a key with X.
+
+
+ ------- Additional Comments From Speeddymon at yahoo.com 2002-05-25 17:17 -------
+ Should this bug be closed? no comment on it for over a year......
\ No newline at end of file
More information about the wine-bugs
mailing list