]> git.mxchange.org Git - flightgear.git/commit
This is an ugly fix for an ugly problem. And no, the two uglies don't cancel
authormfranz <mfranz>
Sat, 12 Nov 2005 10:51:58 +0000 (10:51 +0000)
committermfranz <mfranz>
Sat, 12 Nov 2005 10:51:58 +0000 (10:51 +0000)
commit0eef853caaf81f54f8940c57c2ac4ed0106cdc74
treef84d9670a775d81f5e3e10bad611cdf2034a41e6
parente5d3c3134bf0bfd1c49ebc332322e6349e2453d6
This is an ugly fix for an ugly problem. And no, the two uglies don't cancel
each other out. The problem is this: if we press, for example, "Ctrl-a", but
release the "Ctrl" modifier button *before* the "a" button (which nobody does
intentionally, but which happens all the time), then we don't get the RELEASE
signal on "Ctrl-a" (keycode 1), but on the "a" (79). But "a" hasn't been
pressed, so the signal is dropped. And who releases "Ctrl-a"? Nobody!
So the next PRESSED signal for "Ctrl-a" is ignored, too. It is still
"pressed" after all, isn't it? That's the reason for the occasional
non-functioning of keys.

Due to the nearing 0.9.9 release, I only commit a crude last-minute fix.
It's not as intrusive as it looks, and shouldn't be "dangerous" at all.
It only makes sure that when we get an unexpected RELEASE for one letter
key ("a") that the two twins "A" and "Ctrl-A" are released if they are
still in "pressed" state.

The proper fix will be to let fg_os{,_sdl}.cxx always report presses on the
same key ("a", "Shift-a", "Ctrl-a", "Alt-a", and other combinations of
modifiers) as the *same* key (97), only with modifiers appropriately set.
src/Input/input.cxx