BUG? modifierKeysChanged() ignores keyboard focus and uses component under mouse?

General JUCE discussion
1

The documentation says: “this method will be called on the component that currently has the keyboard focus”.

The JUCE source code says:

void ComponentPeer::handleModifierKeysChange()
{
auto* target = Desktop::getInstance().getMainMouseSource().getComponentUnderMouse();
…
}

…and then proceeds to do things with that pointer.

What’s the intended functionality of that method?
If I have several components which want keyboard focus (mouse clicked on them and then they react to keyboard presses), shouldn’t the above method select the component that has focus currently instead of the one under the HOVERING mouse cursor?

I have a bug now:

  • I use grabKeyboardFocus() to select the component which should receive the keyboard presses.
  • The messages for Shift key still go to the component under the mouse cursor, which is not what I want.

Is this a JUCE bug or documentation error or my own misunderstanding how this thing should work?

1 Like
2

Yes it looks like the documentation for that method is wrong and it should specify that the Component under the mouse will be tried first before the currently focused one. We’ll get that updated.

Component::keyStateChanged() will be called for modifier keys as well and the peer will try the focused Component first - could you use that instead?

1 Like
3

As long as Shift+Tab vs. Tab can be recognised.

4

Just tried what you suggested. keyStateChanged() is called for the Shift, but there is no way in the documentation/source code which lets me actually test if the Shift key is down or not.

1 Like
5

You can use ModifierKeys::getCurrentModifiers() to get the currently down modifier keys and test for the shift key.

1 Like
6

Ah, ofcourse! Now it works. Thank you! :slight_smile: