Switch to getModifiersEx() in processing.app

[processing-bot]

Created by: benfry

This is really just for DefaultInputHandler and EditorButton, now that things have been switched over for core.

[processing-bot]

Created by: benfry

Both Processing.py and Processing-R rely on the old constant to check whether shift is down. Inside handleRun() is the code:

final boolean shift = (modifiers & InputEvent.SHIFT_MASK) != 0;

Sadly, in earlier releases we only set a boolean for whether shift was down. I changed to pass the modifiers for greater flexibility, but we've been burned for it (non-shift modifiers don't appear to be used anywhere), not expecting something as fundamental as these constants to be changed.

Definitions for the old constant for shift:

InputEvent.SHIFT_MASK = Event.SHIFT_MASK;
Event.SHIFT_MASK = 1 << 0;

Unfortunately, the new constant uses a different value:

InputEvent.SHIFT_DOWN_MASK = 1 << 6;

And confirmed that getModifiers() and getModifiersEx() cannot be used interchangeably:

void draw() {
}

void mousePressed() {
  java.awt.event.MouseEvent me = (java.awt.event.MouseEvent) mouseEvent.getNative();
  int modifiers = me.getModifiers();
  int modifiersEx = me.getModifiersEx();
  //boolean shiftOld = (modifiers & java.awt.Event.SHIFT_MASK) != 0;
  //println(shiftOld);
  println("mods and old shift = " + ((modifiers & java.awt.Event.SHIFT_MASK) != 0));
  println("mods and new shift = " + ((modifiers & java.awt.event.InputEvent.SHIFT_DOWN_MASK) != 0));
  println("exmods and old shift = " + ((modifiersEx & java.awt.Event.SHIFT_MASK) != 0));
  println("exmods and new shift = " + ((modifiersEx & java.awt.event.InputEvent.SHIFT_DOWN_MASK) != 0));
  println();
}

So we may need to stick with the old approach and hold our nose. Could swap out a default implementation that sets the old modifiers for backwards compatibility, but is overridden by default, but we're using an abstract class there (again, following best principles), so we might be mucking with method signatures and break things there too.

[processing-bot]

Created by: benfry

Turns out ActionEvent still expects old-style modifiers, so the e.getModifiers() call is more or less “correct.”

There's an open JDK bug for this, but it remains unresolved: https://bugs.openjdk.java.net/browse/JDK-8186024

[processing-bot]

Created by: benfry

Finished swapping the other getModifiers() uses with getModifiersEx() for 4.0 beta 2. Keep an eye out for key issues that change between beta 1 and beta 2.

[processing-bot]

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.