RE: [GD-General] Key handling revisited

[Brian S. <bs...@mi...>]

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Monday, February 11, 2002 3:08 AM
> To: Jamie Fowlston; gam...@li...
> Subject: RE: [GD-General] Key handling revisited
>=20
> I think there are two separate issues, which Brian sort-of talked
about.
>=20
> -Text input. Need to handle international chars,
shift-alt-meta-squiggle
> wierdness and all that. As much as possible, try to get the OS to do
all
> the
> hard work. Usually queue-driven, so you won't miss keypresses. I don't
> know
> anything about macs, but on Windows you just use the WM_CHAR messages.
> They
> will tell you what is printed on top of the key that the user pressed,
and
> handle virtual keyboards and macros and so on. Probably exposed as a
> stream
> of ASCII-like things, except probably 16-bits wide. Could possibly use
> UNICODE?

Ahh, memories.

Just remember that "there is not necessarily a one-to-one correspondence
between keys pressed and character messages generated", as the
documentation for WM_CHAR points out.  It may take a number of key downs
to make that shift-alt-meta-squiggle (Meta?  this better not turn into
another damn Emacs thread!).  Also look into WM_IME_CHAR if you want to
handle double-byte characters in a non-Unicode window.  Otherwise, you
can get two WM_CHAR messages for a single double-byte character.

And of course, you'll get different actual values in your events
depending on whether you're a Unicode window or not.  And Unicode
windows aren't supported directly on Win9x.  Ugh.  Java, anyone? :)

Macs - under the Classic event manager - deal with 8-bit keys and send
the scan code along with the translated char.  I don't know how this has
changed under Cocoa or Carbon.  It would be like a WM_CHARDOWN/WM_CHARUP
combo if such a thing existed.  It's also 8-bit only so if you want to
do Unicode translation you have to buffer up data until you get a valid
conversion result into the current system script - at least, I'm pretty
sure we handled it.

So our x-plat layer used those events above and followed this model:

* send keydown/keyup messages with our own virtual key constants, for
dealing with gameplay presses - sending kLeftArrowKey, etc.
* send Unicode char messages when x number of key presses generated a
valid char, according to the OS

But it would probably be better to poll for the first class of events
and only send the second as actual events, which is the approach Tom
outlines.  Either one is possible.

So happy to not be dealing with this anymore,
=20
--brian