Key device sensor component

Contents:

1. Demos

This components allows to read and process keys using X3D nodes.

Note: If you write a game using Castle Game Engine, this is probably not the most comfortable way to process keyboard. Instead, you probably want to react to TCastleWindowCustom.OnPress or TCastleControlCustom.OnPress or override Press method. See the manual describing handling events.

For demos and tests of these nodes, see the sensors_key subdirectory inside our VRML/X3D demo models.

2. Supported nodes

Both nodes of this component are supported: KeySensor (API reference) and StringSensor (API reference).

TODO: for now, only 8-bit ASCII characters are passed (to the KeySensor.keyPress/keyRelease events, and to the StringSensor.enteredText/finalText)..

Note: keyPress and actionKeyPress events follow the "key repeat" feature of your operating system/window manager. This means that when the user holds down a key, we generate many key press events. Sometimes it's useful (for simulating normal text input, for example). Report if you would like to make this feature optional (and maybe off by default?), a field like KeySensor.repeatKey may be added.

Note: isActive := TRUE is also generated at each key press, and isActive := FALSE at each key release. So they do not match in pairs. And it's not that simple, even if we would turn off the "key repeat" feature mentioned above: imagine that you press one key, then you press a 2nd key, and release the 1st key. Turns out that we have to track all the keys pressed, and deactivate only when all are released, right? Things get more hairy when you consider the first key to be the letter "a", and the 2nd key to be "Shift". Conceptually, "a" is pressed, then "A" is pressed, then "A" is released... but when was lower-case "a" released? Actually, we do have a smart code inside an engine to track it correctly, but it's not passed to the KeySensor yet.

Note: Many X3DKeyDeviceSensorNodes (both KeySensor and StringSensor) may be active at given time. The specification doesn't precisely say what should happen, with wording suggesting that making a sensor enabled makes it also active (which contradicts the KeySensor spec), and without saying which sensor is chosen if many are present (the first? the last in the graph?).

History: KeySensor is in fact the first sensor node implemented long time ago :)