NSViewComponentPeer::isFocused() gets wrong focused Peer


#1

Hi,

the NSViewComponentPeer::isFocused has some problems, when working with shared windows (isSharedWindow == true).
The “currentlyFocusedPeer” has a wrong value or is falsely a NULL pointer depending on the parent app.

bool NSViewComponentPeer::isFocused() const { return isSharedWindow ? this == currentlyFocusedPeer : (window != 0 && [window isKeyWindow]); }

I could only test this with two apps that use shared windows but its 100% reproducable:

AU Lab:
As long as no AlertWindow was opened currentlyFocusedPeer inside NSViewComponentPeer::isFocused has the right value of the Peer that should actually be the currently focused peer.
After an AlertWindow was opened and closed again, the currentlyFocusedPeer will remain the adress of the AlertWindow and won’t be set correctly to the Peer that actually has focus untill the complete Peer is closed and a new one is created.

Logic 8 (maybe this has changed in Logic 9 but I don’t have it, so I can’t check):
currentlyFocusedPeer inside NSViewComponentPeer will only have the right adress of the shared window Peer until you click inside the window for the first time. After that, it will always be a NULL pointer. Note that as long as you only click the top bar of the window for example to move it, the Peer has the correct adress but even clicking in the area where presets and bypass and so on are located, will make the window lose the correct Peer.
I guess this is the reason why logic never gets any mouse enter/exit… events or focus callbacks after a click somewhere inside the window.

Something seems to be not correct when dealing with shared windows. I hope someone has an idea how to fix this or at least a hint where I could start trying to fix it myself.


#2

Yes… it all gets tricky when the window is owned by a 3rd party… But I can’t really see any other way of doing it: if the viewFocusGain and viewFocusLoss methods don’t get called by the OS, then something outside our control must be messing about.


#3

I’m not sure about that but I believe some time ago there was a version of juce that didn’t have that problem. Maybe I’m wrong and I just didn’t realize it back then. I’m not convinced that there is no solution for the problem and I don’t mind spending some days stepping through the debugger, since this is an important feature for all of my plugins.
It would be cool if you could give me some points where to start this task because nobody knows the juce internal platform and focus handling better than you.


#4

I think that previous version that worked was probably the one that used Carbon - now that everything has to use NSViews, it’s all completely different. I’ve got some other urgent stuff at the moment so no time to help debugging it right now, but shout if you find any clues or questions…


#5

Problem with shared windows solved:
With some simple adjustments we can make shared windows, especially for plugins in logic and AU Lab behave correctly. Key input, mouse overs and other focus handling stuff works like a charm with the following adds to juce_mac_NSViewComponentPeer:

Since there is no existing window when the NSViewComponentPeer constructor is called, the “window” variable for shared windows will always be a NULL pointer which leads to a lot of focussing problems (posted in a number of different threads).
To avoid this, we have to add some lines of code to the juce_mac_NSViewComponentPeer, so that the shared view knows the correct value for its parent window:

in “@interface JuceNSView : NSView” add

in “@implementation JuceNSView” add

- (void)viewDidMoveToWindow { if (owner != 0) owner->viewMovedToWindow(); }
to the class “class NSViewComponentPeer : public ComponentPeer” add:

and somewhere below, the implementation:

void NSViewComponentPeer::viewMovedToWindow() { if(isSharedWindow) window = [view window]; }

With these adjustments shared windows work correctly.


#6

Ah, superb stuff! Many thanks!


#7

Many thanks friscokid for this patch :slight_smile: Problem posted by me in another thread is now solved.

Cheers!


#8

This works well for AU and solves my problem of busted text editors. I still have the same issue in RTAS (haven’t tested VST yet). Is there something similar I can do that you might be aware of?

Thanks for posting this solution.


#9

Is this still necessary with the latest tip as of 11 Feb? I’m looking at it for audio plug-in development wise, Thanks!


#10

I think I added that… You’d have to have a quick look to make sure though.


#11

YEP. it is in the latest tip, thanks Jules


#12