This component defines nodes to interact with a keyboard.
KeySensor
processes simple key presses / releases.
StringSensor
provides a simple way for user to type and edit
a string.
See also X3D specification of the Key device sensor component.
Contents:
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.
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 :)
Copyright Michalis Kamburelis and others.
Particular thanks go to Paweł Wojciechowicz from Cat-astrophe Games for various graphics.
Even this documentation is open-source and you can redistribute it on open-source terms,
in particular CC BY-SA.
We use cookies
for analytics.
Like every other frickin' website on the Internet.
See our privacy policy.