Re: Telling apart different save panels
Re: Telling apart different save panels
- Subject: Re: Telling apart different save panels
- From: douglas welton <email@hidden>
- Date: Tue, 20 Sep 2011 21:00:49 -0400
Graham,
I'm not sure that my solution is any "less messy" than what you have suggested, but... when faced with this same situation, I gave the save panel a different title each time it was invoked. When the panel object was passed to my delegate, I could tell where the panel was being used by the title of the inbound object. No need for subclasses or additional retains.
later,
douglas
On Sep 20, 2011, at 6:15 PM, Graham Cox wrote:
> In my app I have two places where a NSSavePanel is used to set up different sorts of file save. Using the modern 'block completion' approach, running the panels as sheets, the code is very nice, self-contained and clean. The save panel variable is a local var in the method that kicks off the panel, and because this internally defines the completion block, that's all that's needed on the face of it.
>
> Problem is, both these uses set the same delegate for the save panel, in order to restrict the panels to certain directories. In the delegate callback, there is no easy way that I can see to tell apart one save panel from another (I'm passed the panel itself, but I can't tell which one it is).
>
> I could of course assign the save panels to an ivar of the delegate so that it can perform a comparison, but that strikes me as pretty messy, given that otherwise the panels are very neatly encapsulated along with their completion blocks. In addition, the delegate class is already complex and broken up into multiple categories for ease of managing the code, and this code lives in a category. Adding an ivar would need to be done in the main class interface file and when you do that to support functionality in a category, you get a warning from the analyser that the ivar is 'unused'.
>
> What would be a clean way to easily distinguish the save panels without having to use ivars?
>
> --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