Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
- Subject: Re: Safe time to add accessory view to NSSavePanel in sandboxed app?
- From: Mike Abdullah <email@hidden>
- Date: Thu, 16 Jul 2015 21:20:39 +0100
> On 16 Jul 2015, at 20:30, Martin Wierschin <email@hidden> wrote:
>
>>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>>> 0 libobjc.A.dylib 0x00007fff8b5b80dd objc_msgSend + 29
>>> 1 com.apple.AppKit 0x00007fff9231bb94 -[NSView _setSuperview:] + 2591
>>> 2 com.apple.AppKit 0x00007fff9231ad78 -[NSView addSubview:] + 436
>>> 3 com.apple.AppKit 0x00007fff92346432 -[NSWindow setContentView:] + 640
>>> 4 com.apple.ViewBridge 0x00007fff93d460c1 setWindowContentView + 75
>>> 5 com.apple.ViewBridge 0x00007fff93d34d42 -[NSRemoteViewBase setAccessoryView:] + 208
>>> 6 <com.myapp> 0x000000010ba36a1d 0x10b9ab000 + 571933
>
>> Is it trying to be clever and re-use existing accessory views, or is a fresh one created each time?
>
> Why do you ask? Is this a known problem?
My thinking is _setSuperview: seems somewhat a surprising place to crash.
I’m hazarding a guess that the accessory view is not a fresh one, and still has a reference to its previous superview. Apple’s code doesn’t expect that situation, and finds the pointer to the previous superview to be invalid perhaps.
This is Apple’s bug, but if my guess is correct, you could probably work around it by manually _removing_ your accessory view from NSSavePanel once the panel returns, rather than leaving semi-attached there.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden