Re: Blocking while a save panel sheet is showing
Re: Blocking while a save panel sheet is showing
- Subject: Re: Blocking while a save panel sheet is showing
- From: Graham Cox <email@hidden>
- Date: Tue, 15 Feb 2011 10:20:07 +1100
On 15/02/2011, at 12:09 AM, Kenneth Baxter wrote:
> My understanding of what the framework does is:
>
> [delegate saveData];
> if (dataHasBeenSaved) {
> do stuff
> } else {
> do different stuff
> }
>
> So if my delegate method saveData uses the sheet to save, it will return from the saveData method immediately, no matter what I do. I do have the file saving code in the completion block of the sheet, but by then it's too late - the framework thinks the data wasn't saved.
>
> I'm afraid I can't see a way to refactor that so that saveData doesn't return until the save operation is complete, and I can't see how the framework could work properly without waiting for the completion of the save operation.
>
> Maybe I'm missing something obvious about the way this is supposed to work (I'm still rather new to all this), or some other option. I did try to have a look at the document saving system, since it seems to be able to wait for the open documents to be saved on quit before deciding if the application should quit, but I didn't fully understand that, and I think it may operate in a different way than what I need.
>
Hmm, I see your problem. Looks like bad design/poor assumptions/arrogance on the part of the framework.
Is the framework in charge? I mean, is there something you can do that causes the framework to take this pathway, rather than be at its beck-and-call? If so then put that trigger in your sheet callback. I really dislike framework code that pushes stuff at you like that. What it should do is quietly store the data until you ask for it, at which point it should obediently return it.
Otherwise Ken's suggestion of running the save dialog modally is about your only option, though if you do have a document-based app, that's not considered a good UI.
--Graham
_______________________________________________
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