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: Martin Wierschin <email@hidden>
- Date: Thu, 16 Jul 2015 14:00:56 -0700
That logic makes good sense Mike. Unfortunately it doesn't seem to avert the crash. My own app, which still encounters this crash from time to time, actually already does what you suggest: after the save operation has been completed, the accessory view removes itself from the NSSavePanel by calling [panel setAccessoryView:nil].
And after reviewing my code, it turns out that my app doesn't recycle/reuse accessory view instances after all. I thought it still did, but that was some time ago, when the open/save panels were slow as death under sandboxing.
~Martin Wierschin
> 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