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 (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
