From: Stefan Holdermans <stefan@cs...> - 2007-03-22 15:07:54
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
the event carries
Besides with wxMac, I've also experienced this agressiveness with
wxGtk 184.108.40.206 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.
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?