selectInput() anomaly

Greetings all,
I’ve encountered some anomalous behavior regarding the selectInput() function and the P3D renderer that I’m curious about. I’m running on a Windows 10 system.
The following dummy code demonstrates the behavior. When running, it waits for keyboard input. With each keystroke, the the key and keyCode are printed to the console. Any one of three keys (L, O, or R) will initiate the selectInput() function and open the file selection window. The user can either select a file or cancel, and the program will resume. The strange thing that occurs on my system when using the P3D renderer is that whenever the selectInput() function is called, the key which called it will apparently be disabled for one (and only one) keystroke. It won’t even be caught by the keyPressed() function. No other keys are affected at all.
The problem disappears when the default renderer is used.
This isn’t a big issue–just hit the key twice and selectInput() will be called, but I’m curious why it happens, and wonder if there could be related issues. I’ve also had occasions when the selectInput() function immediately returns a null response without any user input. And I’ve had crashes when it’s called. These last two issues can’t be duplicated with a simple code snippet, but seem to occur pretty regularly for me.
Anyone have any thoughts on the subject?

String fileName;
boolean fileSelectedYet = false;

void setup() {
  size(200, 200, P3D);

void draw() {
  if (fileSelectedYet) {
    fileSelectedYet = false;
    println("File:", fileName);

void keyPressed() {
  println(keyCode, key);
  switch (keyCode) {
  case 76:      //'L'--Load
  case 79:      //'O'--Open
  case 82:      //'R'--Read
    selectInput("Select a file to process:", "fileSelected");
  case 81:      //'Q'

void fileSelected(File selection) {
  if (selection == null) {
    println("Window was closed or the user hit cancel.");
    fileName = null;
  } else {
    fileName = selection.getAbsolutePath();
    println("User selected " + selection.getAbsolutePath());
1 Like

I’m not sure – it sounds like some interaction between the callback and the event, but surprising that it is renderer-specific – that might have something to do with the difference between java.awt.Event and JOGL NEWT events – see Back/forward/extra mouse buttons – but this is beyond my ken right now. if you have documented this with a test sketch I would recommend submitting it as an issue to: