Why is the function keyPressed not working?

edited January 2018 in Questions about Code

I wrote a similar program with function keyPressed:

void setup() {
  size(1010, 700);
  background(0);
}

int mykey = 0;

void draw() {
  if (mykey > 0) {
    stroke(0); fill(0);
    rect(100, 200, 100, 50);
    stroke(#dddddd); fill(#dddddd);
    textAlign(LEFT, CENTER);
    text(mykey, 105, 208);
    mykey = 0;
  }
}

void keyPressed() {
  if (key == CODED) {
    mykey = keyCode + 256;
  } else {
    mykey = key;
  }
}

... but it work only then I first click with mouse on the display window after start program. That's wrong? I do not want to use the mouse.

Tagged:

Answers

  • Answer ✓

    So true! I have this in Windows 10, that the running sketch window does not automatically receives the focus from the processing IDE.

    Very annoying.

    Maybe a bug?

    I guess when you compile and start the exe, it will have the focus immediately.

  • Answer ✓

    I wrote a hackish code using the robot lib to bring the mouse to the window and click it for you. If you are interested, I could get it for you.

    Kf

  • How are you running this? Does this problem only happen with sketches you run from the Processing editor? What about exported applications?

    The window needing the focus to receive key events is not a bug. Windows can't receive key events unless they have the focus. But the window not getting the focus in the first place might be a bug, but probably not a very high-priority one.

  • Thanks for answers.

    To KevinWorkman: This problem happen every time. With sketches I run from the Processing editor and with exported aplications too. But I think its bug. Because I must click on display window (here I mean the graphical area that is defined by the command size()). If i click on the header of this window is still not working...

    To kfrajer: Well thank you. I am interested in.

  • edited February 2018

    the window not getting the focus in the first place might be a bug, but probably not a very high-priority one.

    I'm not sure I agree that should be low priority. Depending on if non-focus is the default and a widespread problem -- that could present an accessibility problem for people using assistive interfaces who don't or can't mouse. I would suspect that a basic level of accessibility (like "people who can't use a mouse can still run interactive sketches) falls within Processing Foundation's core mission...

    Of course, if you can just hit Ctrl-Tab or whatever....

  • I have no problem using the mouse. But there are cases where it is useless ... (login, data entry, etc.). And especially when signing in if the first step is to enter a password, why is my mouse? She will come to the advice later. That's why I need an in-app focus right after running the app.

  • Good to know, and I see your point.

    I wasn't saying that you have an accessibility problem -- I was just saying if people could have one then that might make a mouse-required issue higher priority for Processing.

  • I'm not sure I agree that should be low priority.

    You might be right. I didn't want to make it sound like I was the one setting the priority or anything. It was just a guess.

    Feel free to file this bug on Processing's GitHub. Let us know what you hear back.

Sign In or Register to comment.