Label and keyboard focus

Audio Plugins
1

Hi,

this is probably a noob question, but I am not sure how to handle this properly. The host is Pro Tools, and I have set JucePlugin_EditorRequiresKeyboardFocus to 0.

How can I get the TextEditor to open when I click on a Label? It does work with JucePlugin_EditorRequiresKeyboardFocus set to 1, but then the user would have to switch focus first before using any standard Pro Tools key commands.

Thanks,
(a)

2

Yeah, all that stuff is a bit tricky. You might manage it just by calling setWantsKeyboardFocus (true) on the appropriate comps, but maybe do a search for JucePlugin_EditorRequiresKeyboardFocus in the source code to get an idea of how fiddly it is.

3

Hmmm, not sure what is called by whom, but can setWantsKeyboardFocus () really work under Win32 when you have

void globalFocusChanged (JUCE_NAMESPACE::Component*)
{
#if ! JucePlugin_EditorRequiresKeyboardFocus
    if (hasKeyboardFocus (true))
        passFocusToHostWindow (hostWindow);
#endif
}

in EditorCompWrapper?

Just clueless,
(a)

4

Yeah, that’s what I mean - it’s quite a difficult balancing act to get keyboard handling to work alongside the host.

5

Is there any possibility to pass the focus manually to the host window? So that you could do that from the Editor?

Thanks,
(a)

6

You could have a go with native windowing calls and see what happens…

7

I have a problem that may have affinity to this… On MacOS X, when compiling my plugin as AU, I can’t get ANY keyboard events if I debug in AU Lab. Compiling as VST and using VSTi Host to debug, keyboard events hapen just fine.

Any hints?

  • A
8

Hi,

although I have been able to find a simple workaround for the problem on Windows RTAS (just don’t pass the focus on to the host window if one component is modal), I still have problems with Mac Os. Since I am not very familiar with Mac Os I would welcome any suggestions.

I am still trying to get my head around to the functionality of setWantsKeyboardFocus(). In Windows, the call to this function doesn’t matter too much, but in MacOs RTAS, setting this to false for the top level component results effectively in setting it to false for all children as well, as far as I understand.
So, either the PluginEditor generally accepts keyboard focus, allowing its children to accept focus as well but at the same time stealing focus from the host unnecessarily with every click, or it refuses keyboard focus for all of its children.

Did I understand that correct, and if yes, are there any suggestions to solve/work around this?

I am just not a Mac guy, you know…

Thanks,
(a)

9

No workaround, but some more information that will hopefully help solve this.

I am experiencing the problem too. I previously had setWantsKeyboardFocus(true) called on the top level component, which allowed all subcomponents to get focus. However, I found that no keyboard events would get passed back to Pro Tools.

If I call setWantsKeyboardFocus(true) on individual components (not the top level component), it doesn’t work.

If I call setWantsKeyboardFocus(true) on the top level component, I can call setWantsKeyboardFocus(false) on subcomponents, which will prevent them receiving focus.

The text box associated with a slider is a special case. If setWantsKeyboardFocus() is called on a slider, the textbox is not affected. This is a problem for my plug-in, but ought to be easily solvable.

I’m hoping I can find a workaround for this by installing a keyboard handler and passing events back to the native window. I don’t know yet if this will be possible. Ideally, though, setWantsKeyboardFocus() would work properly…

10

Installing a keyboard handler doesn’t work… because the top level component must be able to accept focus.

More info: at least part of the problem seems to be with the top level ComponentPeer. In Component::takeKeyboardFocus (the Component object being a text editor - which does have the wantsKeyboardFocus flag set, contrary to my previous post), peer->grabFocus() is called, which seems to work fine. However, on the next line, peer->isFocused() fails, unless the top level component has the wantsKeyboardFocus flag set. I think it is failing because the isKeyWindow flag is not set. Seems like there is a discrepancy here…

11

I seem to remember that the isKeyWindow method behaves a bit strangely, but couldn’t work out why - probably just a quirk of the cocoa windowing system.

12

Any suggestions as to a workaround for this? This is the last blocking UI bug for us… I’m stuck when it comes to debugging this further - I don’t know any objective c/c++. Or is it something that’s on your radar to fix?

13

Although isKeyWindow doesn’t seem to be behaving correctly, it isn’t even the source of the problem… I can comment out the call and the problem still happens. I am completely stuck…

14

It’s on my radar, but slightly snowed under at the moment…