processing / processing/processing4

keyPressed() does not always fire after starting sketch

Open
#766 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
494
Forks
183
Avg merge
4h 39m
Merged PRs (30d)
3

Description

Created by: sterretjeToo

When starting a sketch from the IDE or running an exported sketch, it does not always react on keyboard input; sometimes one has to click inside the drawn area. So it looks like a started sketch does not have the focus; clicking on the titlebar in the window does not solve the issue.

The below sketch (running in the IDE) produces the issue (as said, it sometimes works correctly, sometime not).

void setup()
{
  size(400, 200);
}

void draw()
{
}

void keyPressed()
{
  println("keyPressed()");
}

Expected behaviour

The expected behaviour is that at the moment that the sketch runs and a key is pressed, the message "keyPressed()" shows.

System information

Second gen Intel I3 with 8GB memory and integrated Intel Graphics (AsRock H61M VS-R2.0)
Windows 10 Home
Processing 4.3; the issue was also observed in Processing 4.2)

Workaround

https://discourse.processing.org/t/keypressed-only-works-sometimes/22340 (July 1920) contains a (possible) workaround by using the below line in setup()

  surface.setVisible(true);

For now, it seems to have solved the issue. I will provide feedback if I still encounter the issue with the above workaround.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Run the provided minimal sketch from both the IDE and an exported sketch on Windows, testing whether keyPressed() fires immediately without clicking the drawing area. Start by comparing sketch startup and window focus/visibility behavior, including the reported surface.setVisible(true) workaround. Done means keyboard input works reliably immediately after launch in both cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.