From: Stefan H. <st...@cs...> - 2007-03-22 15:07:54
|
Hi all, I've ran into a quite annoying problem... The key events wxHaskell allows you to handle originate from so- called char events at the wxWidgets side. These carry 'translated' key codes. For instance, when the 'A'-key is pressed while the SHIFT- key isn't (nor is CAPS LOCK etc.), the char event will carry the ASCII code for 'a', i.e., 97. However, when the 'A'-key is pressed together with the SHIFT-key, the char event will carry the ASCII code for 'A' (upper case), i.e., 65. The ratio behind all this is that's it's cumbersome to explicitly find out whether which modifiers (SHIFT, ALT, etc.) come with which key press. (wxWidgets, by the way, also offers 'untranslated' key events that just let you inspect the key code for the pressed key. The point here is that wxHaskell works with the _translated_ events.) So far, so good. Unfortunately, so I find out, I run an incarnation of wxWidgets, i.e., wxMac 2.6.2, that translates key events a bit too agressive. For instance, pressing the up-arrow key results in a translated event that carries the ASCII code for a form separator '\RS'. So, instead of the expected value KeyUp the event carries KeyChar '\RS' Besides with wxMac, I've also experienced this agressiveness with wxGtk 2.6.3.3 on Gentoo Linux. Right now, I work around it by defining my own event constructors: module MyGUI where import Graphics.WX.UI hiding (upKey, downKey) ... upKey = charKey '\RS' downKey = charKey '\US' Still, it is of course quite annoying. It would suit me better if wxHaskell would work with untranslated key events. This boils down to adapting the Reactive instance for Window: instance Reactive (Window a) where ... keyboard = newEvent "keyboard" windowGetOnKeyDown windowOnKeyDown ... I'd be more than happy to supply a patch for this. Any thoughts? On a related note: handlers for key events that I attach to frames do not seem to have any effect at all. Can someone explain to me why? Cheers, Stefan |