Re: NSSavePanel problem
Re: NSSavePanel problem
- Subject: Re: NSSavePanel problem
- From: Andy Lee <email@hidden>
- Date: Sat, 23 Feb 2013 22:44:34 -0500
On Feb 23, 2013, at 9:57 PM, Quincey Morris <email@hidden> wrote:
> On Feb 23, 2013, at 18:12 , Andy Lee <email@hidden> wrote:
>
>> Also, to repeat part of Graham's question: is the window you're attaching the sheet to a floating window or a regular window? Maybe the sandboxing is irrelevant.
>>
>>> How do you run it as a panel standalone - as opposed to as a sheet ?
>>
>> I don't remember the method name offhand, but you'll find it if you look at the docs for NSSavePanel. If you try it and the crash goes away, please let us know -- I'm curious.
>
> Peter didn't run it as a sheet. You can see in line 30 of the backtrace that his app invoked -[NSSavePanel runModal].
Ah, right. I'm puzzled by the question then.
> Also, according to the backtrace, the crash occurred in Cocoa frameworks (well, Apple frameworks, since it's in C++ code), so I wouldn't hare off looking for app memory management errors without any evidence supporting the idea.
Can you say more about this? I thought it was possible for a memory error -- especially a dangling pointer -- to have a delayed effect such that there's no telling when it will cause a crash. Is there something about these particular symptoms and this stack trace, besides the fact that it happens in Apple's code, that rules out (or makes very unlikely) an error in Peter's code? Perhaps the fact that it's so repeatable?
> Rather, I think Graham's closer to being on the correct track. I've noticed that 10.8 NSSavePanel does have a tendency to explode, for reasons that are unclear. When it does that, it continues to explode until you find a way of getting it past the triggering condition. After that, it behaves properly until the next time.
>
> My guess is that 10.8 re-architected NSSavePanel (to better support sandboxing, but affecting non-sandboxing too) in such a way that there is persistent state stored outside the application. For that reason, quitting the app doesn't necessarily clear the problem.
>
> My guess is that in Peter's case the popup contains an entry that is no longer valid. It's possible that clicking the Save button without popping up the menu will clear it, or perhaps using the Save panel of a different application, or rebooting. Or possibly there's a preferences file that could be deleted.
>
> That's all speculation,
But plausible.
> but given the backtrace there's really no evidence the crash is Peter's fault.
This falls a little short of saying it's definitely not caused by a bug in Peter's code, so I'd like to be clear: is that what you're saying, and if so, can you explain a bit more?
--Andy
_______________________________________________
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