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,

• These nodes are not the most comfortable way to process keyboard. Do not use them.

• Instead, override TUIState.Press method to listen to keys (see any "New Project" template created by the editor for an example). You can also react to TCastleWindowCustom.OnPress or TCastleControlCustom.OnPress or override Press method. See the manual describing handling events.

• If you definitely want to use these nodes with CGE, remember to set TCastleSceneCore.ListenPressRelease to true.

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

2. Supported nodes

• KeySensor (API reference)

  Listen to key press and release.

• StringSensor (API reference)

  Input and edit a string using keyboard.

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?).