Juce AU host not giving keyboard focus to plug-ins

Audio Plugins
1

We use Juce for doing AU hosting. We’re getting a bug where the host does not seem to pass keyboard events to most plug-ins. The only plug-in that I can get keyboard focus for is the Juce demo plug-in.

I see the same problem when I try the Plugin Host demo. When I run the prebuilt Plugin Host demo from Juce 1.51, it does not seem to pass keyboard focus to a plug-ins editor, except for the Juce demo plug-in which works fine. For example, if you click on a plug-ins text editor, you then can’t edit the text. I tried setWantsKeyboardFocus(true) on the Plugin Host PluginWindow and the AudioProcessorEditor components.

With the latest version from GIT, the demo plug-in works fine with in the Plug-in Host demo, but now in this version, no mouse events seem to be received by any other plug-ins.

I saw that there have been many posts about Juce plug-ins not getting focus from various other hosts, Cubase, Live etc.
Although we have opposite problem, perhaps its related, so I wondered if anyone had thoughts or suggestions about where the problem could be originating before I dig a bit deeper?
Thanks!

2

It’s the responsibility of the plugin to get the events, so there’s not really anything that the host needs to do… Maybe these are old carbon plugins that are struggling to run in a cocoa host?

3

Yes they are carbon only AUs.

Do you have any ideas of some good starting points for looking into this problem?
Thanks

4

If you want to poke around, have a look for the AudioUnitPluginWindowCarbon class.

5

Hi Jules,

I took a look at this and managed to fix it. Here’s the diff:

diff --git a/src/native/mac/juce_mac_CarbonViewWrapperComponent.h b/src/native/mac/juce_mac_CarbonViewWrapperComponent.h
index 1d480e1..1678ada 100644
--- a/src/native/mac/juce_mac_CarbonViewWrapperComponent.h
+++ b/src/native/mac/juce_mac_CarbonViewWrapperComponent.h
@@ -88,7 +88,7 @@ public:
             if (wrapperWindow == 0)
                 return;
 
-            NSWindow* carbonWindow = [[NSWindow alloc] initWithWindowRef: wrapperWindow];
+            carbonWindow = [[NSWindow alloc] initWithWindowRef: wrapperWindow];
             NSWindow* ownerWindow = [((NSView*) getWindowHandle()) window];
 
             [ownerWindow addChildWindow: carbonWindow
@@ -99,15 +99,7 @@ public:
             EventTypeSpec windowEventTypes[] =
             {
                 { kEventClassWindow, kEventWindowGetClickActivation },
-                { kEventClassWindow, kEventWindowHandleDeactivate },
-                { kEventClassWindow, kEventWindowBoundsChanging },
-                { kEventClassMouse, kEventMouseDown },
-                { kEventClassMouse, kEventMouseMoved },
-                { kEventClassMouse, kEventMouseDragged },
-                { kEventClassMouse, kEventMouseUp},
-                { kEventClassWindow, kEventWindowDrawContent },
-                { kEventClassWindow, kEventWindowShown },
-                { kEventClassWindow, kEventWindowHidden }
+                { kEventClassWindow, kEventWindowHandleDeactivate }
             };
 
             EventHandlerUPP upp = NewEventHandlerUPP (carbonEventCallback);
@@ -224,7 +216,7 @@ public:
             child = HIViewGetNextView (child);
         }
     }
-
+	
     void timerCallback()
     {
         setOurSizeToEmbeddedViewSize();
@@ -247,6 +239,8 @@ public:
             case kEventWindowGetClickActivation:
             {
                 getTopLevelComponent()->toFront (false);
+
+                [carbonWindow makeKeyAndOrderFront:nil];
 
                 ClickActivationResult howToHandleClick = kActivateAndHandleClick;
 
@@ -269,6 +263,7 @@ public:
 
 protected:
     WindowRef wrapperWindow;
+    NSWindow* carbonWindow;
     HIViewRef embeddedView;
     bool recursiveResize;
     Time creationTime;

Any chance this can go into the trunk of Juce?

Thanks,

Geert

6

Ok… I can believe that makeKeyAndOrderFront might help it get focus, but I don’t understand why you’ve deleted all the event callbacks?

7

Hmmm, I did that since there wasn’t really anything responding to those … so there’s no reason to have them there. Note though that I’m very much a novice at Carbon/Cocoa so I might be missing something.

8

Those events were there to force the cocoa/carbon bridge to consume them correctly - it may be that Apple have tweaked the OS since I did that and made them unnecessary, but it’s not wise to mess with it!

But thanks, I like the sound of your suggestion, I’ll probably add that!

9

Ok, thanks Jules, I removed them after checking in other open-source projects and looking at the Apple tech-note. Everything still works without them on Snow Leopard, but of course maybe on other versions it might not.