Thrown exception in VE Pro in AU editor instantiation on develop

Audio Plugins
1

Hello!

I’m getting an exception thrown in Vienna Ensemble Pro when creating the Audio Unit editor on the develop branch. The 5.3.2 release is fine. This can be reproduced with a simple synth plugin generated by the Projucer on the develop branch.

The relevant section of the stack trace is:

2018-10-23 09:43:30.465602+0100 Vienna Ensemble Pro[68363:2368137] *** Assertion failure in +[NSView _findFirstKeyViewInDirection:forKeyLoopGroupingView:], /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSView.m:14337
2018-10-23 09:43:30.468032+0100 Vienna Ensemble Pro[68363:2368137] [General] this method is supposed to only be invoked on top level items
2018-10-23 09:43:30.477862+0100 Vienna Ensemble Pro[68363:2368137] [General] (
	0   CoreFoundation                      0x00007fff8566e2cb __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fff9a48748d objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff85673042 +[NSException raise:format:arguments:] + 98
	3   Foundation                          0x00007fff870bbc80 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
	4   AppKit                              0x00007fff8339e4ca +[NSView _findFirstKeyViewInDirection:forKeyLoopGroupingView:] + 159
	5   AppKit                              0x00007fff832905db _replacementKeyViewAlongKeyViewPath + 301
	6   AppKit                              0x00007fff83290204 -[NSView nextValidKeyView] + 232
	7   AppKit                              0x00007fff83118cdb -[NSView(NSInternal) _setHidden:setNeedsDisplay:] + 1362
	8   NewProject                          0x0000000119d1aabc _ZN4juce19NSViewComponentPeer10setVisibleEb + 76
	9   NewProject                          0x0000000119b6d555 _ZN4juce9Component10setVisibleEb + 629
	10  NewProject                          0x0000000119d16753 _ZN4juce19NSViewComponentPeer24redirectWillMoveToWindowEP8NSWindow + 131
	11  NewProject                          0x0000000119d12049 _ZN4juce15JuceNSViewClass16willMoveToWindowEP11objc_objectP13objc_selectorP8NSWindow + 57

It seems to be the call to NSView:setHidden:true when the NSView is being set to invisible in the NSViewComponentPeer class, here:

 void setVisible (bool shouldBeVisible) override
 {
     if (isSharedWindow)
     {
        [view setHidden: ! shouldBeVisible];
     }
     else
     {
...

It seems to be being triggered by change of first responder during this call where the first responder becomes the next valid key view:
https://developer.apple.com/documentation/appkit/nsview/1483369-hidden?language=objc

Those callbacks in turn cause the exception.

Adding a check to see if the view is the first responder, and then before hiding the view setting the first responder to nil, seems to fix it for me. Although I’m not 100% sure of any side-effects in JUCE or the host apps of course!

void setVisible (bool shouldBeVisible) override
{
    if (isSharedWindow)
    {
        if (shouldBeVisible)
            [view setHidden: false];
        else if ([window firstResponder] == view && [window makeFirstResponder: nil])
            [view setHidden: true];
    }
    else
{
...
2

ah that’s not right

3 
void setVisible (bool shouldBeVisible) override
{
    if (isSharedWindow)
    {
        if (shouldBeVisible)
            [view setHidden: false];
        else if ([window firstResponder] != view || ([window firstResponder] == view && [window makeFirstResponder: nil]))
            [view setHidden: true];
    }
    else
{
...
4

What happens if you attempt to set the first responder to view's nextValidKeyView (rather than letting the callbacks do it)?

5

That throws the same exception

6

https://github.com/WeAreROLI/JUCE/commit/3c121b8538a6a922ae9eb76a81738e3de823e544

1 Like