We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Tested in Processing 3.0b5 on Windows 7 (64bit). Use the following code to replicate the behavior:
void setup() {
size(200, 200, P2D); // Comment out to test with the default renderer
}
void draw() { }
void keyPressed() {
println("Key: " + (int)key);
println("KeyCode: " + keyCode);
}
At least INSERT, HOME, PAGE_UP, DELETE, END, PAGE_DOWN and F1 - F12 are affected.
Edit: Thanks for moving, I wasn't sure about where to post bug reports (as I have no github account).
Answers
I guess that NEWT's KeyEvent returns other key and keyCode values than AWT's KeyEvent. But as it could be connected to the OS, could someone confirm that this is also happening on other platforms..? @codeanticode @PhiLho @quark @GoToLoop
Just test the output for the DELETE key. In the default renderer (JAVA2D) it prints (as expected):
While in P2D and P3D it will output:
At least on my PC.
Can't do any testing as away on holiday. Processing wraps up the native event object in its own class
processing.event.KeyEvent
The
keyCode
andkey
values should be the same for all renderers and OS since PS is supposed to be cross platform, so this sounds like a bug.Oh, have a nice trip @quark. ;)
Jub, the wrapping takes place in the nativeKeyEvent methods from PSurfaceAWT and PSurfaceJOGL.
Looking at PSurfaceJOGL's nativeKeyEvent, it seems like only a few NEWT key codes get actually converted to AWT key codes...
Just adding a simple switch statement to convert from NEWT to AWT key codes solves the problem:
Could someone with an github account report this bug and the given solution? :)
The following sketch will compare the virtual key codes of NEWT and AWT and print out all of the differences:
This could be used to create a map for a more efficient (and cleaner?) key code conversion (than if-else-chains or switchs).
Update: NEWT/AWT keyCode inconsistency is still an issue in Processing 3.0 b7.
List of inconsistent keyCodes: