Processing Error In Reading Keyboard Coded Keys

Jim_Plaxco

Using Processing 3.2.3 on WIndows 7 Pro, here is the code to test:

void keyPressed() { println("key="+key + " and code="+keyCode); if(key == CODED) println("code="+keyCode); else println("key=" + key); }

Running this code in one sketch I get the following output when I press the F1 key:

key=? and code=112 code=112

Running the same code in the Processing example program ArcLengthParametrization, I get the following output when I press the F1 key:

key=? and code=97 key=?

This makes no sense. Why would one sketch recognize the F1 key and return one keyCode value while the other sketch does not recognize the F1 key and returns a completely different value?

One point of note. The first result is what I see when running in a sketch that uses only one tab. The second result is what I see when running in a sketch that has more than one tab.

So what does the number of code tabs have to do with how Processing reads the keyboard? Ideas? Does anyone else see this same problem?

Jim_Plaxco

Just noticed the following. The behavior appears to be linked to whether or not their is a P2D or P3D render parm on the Size statement.

Adding either P2D or P3D results in Processing not recognizing the pressing of a function key, F1 for example.

If there is no parameter or the parameter is FX2D, then Processing correctly recognizes the F1 key.

GoToLoop

https://GitHub.com/processing/processing/issues?utf8=✓&q=is:issue is:closed f1

Jim_Plaxco

Thanks GTL. That's it. I solved the problem on my end by changing my code to add a third code block that tests the keyCode value for function keys separately.