I'm getting an exception thrown by the NSPopover code when a popover is going
away. Due to the way popovers are handled, the exception is not one I'm able to
catch, so the app is terminated. This is a very big punishment for what seems a
trivial transgression that doesn't even matter at this time, nor one I have any
apparent control over.
Here's the upper part of the stack trace of the exception:
2015-03-03 09:59:07.164 LogicBoard[44305:3418051] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason: 'The
contentViewController ((null)) or contentViewController.view is nil.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff90bdc66c
__exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff869f776e
objc_exception_throw + 43
2 CoreFoundation 0x00007fff90bdc51d
+[NSException raise:format:] + 205
3 AppKit 0x00007fff8958e89d -[NSPopover
showRelativeToRect:ofView:preferredEdge:] + 249
4 AppKit 0x00007fff89bff304
__53-[NSPopover showRelativeToRect:ofView:preferredEdge:]_block_invoke + 94
5 AppKit 0x00007fff895ac6aa -[NSPopover
_executeClosingBlock] + 31
6 AppKit 0x00007fff895ac517 -[NSPopover
_finishClosingAndShouldNotify:] + 197
7 AppKit 0x00007fff89491204 -[NSWindow
_windowTransformAnimationDidEnd:] + 380
8 libdispatch.dylib 0x000000010025c2bb
_dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x0000000100256d43
_dispatch_client_callout + 8
10 libdispatch.dylib 0x0000000100265d9f
_dispatch_main_queue_callback_4CF + 1370
11 CoreFoundation 0x00007fff90b2fc79
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
12 CoreFoundation 0x00007fff90aec30f
__CFRunLoopRun + 2159
What it's complaining about is that the viewController, or its view, is nil.
The thing is, I do supply this controller and the view is there - in fact it's
been successfully displayed, interacted with and dismissed by this point - this
stack trace is the result of dismissing the popover after I'm done with it. At
this time, it shouldn't care whether it has a view controller or a view -
presumably it will release the view controller it holds anyway at this time, so
it appears as if the exception is completely spurious.
This is happening on 10.10. It's been a while since I worked on this code, last
time was under 10.8, and I don't recall that I was getting this exception in
the same situation there.
This is the code that displays the popover. It's not very interesting, and the
try/catch block here doesn't trap the above exception, because it's actually
nothing to do with it, even though at first glance it appears to be thrown by
the same function.
- (void) displayPopoverForDeviceLayer:(LB_DeviceLayer*) dvl
{
NSRect popRect = dvl.frame;
NSViewController* devViewController = [dvl
viewControllerForAuxiliaryContent];
if( devViewController )
{
self.auxiliaryContentPopover.contentViewController =
devViewController;
self.auxiliaryContentPopover.behavior =
NSPopoverBehaviorSemitransient;
NSView* contentView = devViewController.view;
NSAssert( contentView, @"no view supplied by controller");
//<---- never asserts, there is always a controller and view here
self.auxiliaryContentPopover.contentSize =
contentView.frame.size;
@try
{
[self.auxiliaryContentPopover
showRelativeToRect:popRect ofView:self preferredEdge:NSMaxXEdge];
}
@catch (NSException *exception)
{
NSLog(@"huh?!"); //<---- never invoked
}
}
}
Is this just a case of the popover code on 10.10 being over-zealous about
asserting that it has a controller, even though it doesn't need one once the
popover is dismissed?
I'm at a loss as to how to sort this problem out - the closure block for the
popover is invoked automatically, not by my code, so I'm not seeing any way to
fix this.
--Graham
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
