I am working on an AU Instrument using juce, and I have problem with keyboard focusing in labels.
On clicking a Label I pop a custom texteditor, implementing the virtual TextEditor* method. When the value is changed keyboard focus is not returned to the host, so any play/stop commands or such to not get through to my AU Host (in my case, Logic).
I cannot find any documentation on how to return focus to host application after focus has been grabbed by a component.
Thanks,
Martin Saleteg
Well there’s no easy way of returning keyboard focus, because how can the plugin know where the focus used to be!? If you click on Logic, the focus returns, right?
That is correct, focus returns when I click in Logic again. Perhaps there is a way to store previous ControlRef and return to it after editing is done?
You could do that yourself, I guess. Juce doesn’t really have any way of explicitly getting rid of focus.
Ok, I noticed other plugins handle this correctly, I’ll have a look at it.
/Martin
I can’t think of a good way of doing it automatically - it would probably have to be something your plugin does explicitly before and after showing an editor.
Here’s what I’ve just got from the Apple AU developer support:
“One remark about filtered key commands: you can debug your key event handler and check if it properly returns eventNotHandledErr for un-processed key commands.”
Ah - that’s quite an interesting point. To do that would require some really big changes to the way juce handles keyPresses, but I’ll have a think about it.
Actually, if you want to pass all keys through, you only need to change the handleKeyEvent() method in the juce_mac_windowing.cpp. It might actually not cause any problems if it always returned eventnothandled.
Well, that’s not my case, unfortunately.
I have few TextEditor’s with which you can type in a new value for some parameters.
However, it seems that I’m almost done with some patching in order to correcly ignore key events but when in a modal loop, as required by Logic.
Now an “old” issue remains: when a label gets double clicked, a very small dialog window with a TextEditor in its content area is ran modally. In that condition, the user should be free to type in a new value.
This sometimes doesn’t work: from time to time when you press some keys, they don’t reach the edit field (note that the caret is correctly blinking and I have no extra CPU loads or other background job running).
If I just click the mouse inside the editor, it start working.
If the bad condition isn’t so regular because it pops up after 2/3 times I open the TextEditor, the mouse click trick always fixes it.
Any idea about the reason for this to happen?
You could try calling grabKeyboardFocus on the texteditor after it’s been shown? Just sounds like focus isn’t always being given to that window correctly.
I’m already trying any kind of those things (I even tried simulating a mouse down/up event inside the text box…)
It’s not that the editor totally doesn’t work: it gets the first “key repeat” events for a kept down key and then, whatever is the next key I’m pressing, the previous repeated character is printed out, only at new key repeat time.
It looks like juce starts the modal loop in a keyboard/mouse icomplete condition and that everything goes ok after the mouse click.
This only happens on Mac (Logic and Live), and has nothing to do with my recent modifications because we experienced this problem far before I started with those.
Weird… Have you tried getting the tip from sourceforge? I’ve just been changing the way mac keycodes are processed. (Don’t think it’ll make any difference to this, though…)
