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 (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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to