Hi Quincey. That occurred to me too but seems a bit hackish. I solved it by asking the delegate for the settings name root. The delegate is a distinct class in this case, so it can return a unique string, and the delegate can be set in IB and so is available at -awakeFromNib time. Works well in this case though if the delegate weren't a unique instance it would simply move the problem elsewhere - though I guess you could just keep going up through a chain of delegates until someone could return an unambiguous answer...
--Graham On 06/05/2010, at 3:22 AM, Quincey Morris wrote: > On May 5, 2010, at 05:42, Graham Cox wrote: > >> The problem should be obvious - how to ensure that each instance of the >> controller can use a specific unique key in the user defaults. Creating a >> unique key is easy, but at load time how to calculate the exact same key for >> the specific instance is not. I thought of adding a 'settings name' property >> that was used to prefix the key but there's no way to set it earlier than >> -awakeFromNib time from some external object that "knows" which instance it >> is using. Ideally the settings name could be set for the instance in IB, but >> since this is a generic NSObject subclass I can't do that without making an >> IB plugin just to set it, which seems like major overkill. >> >> Is there another way to set the settings name just in time? > > The first thing that sprang to mind was to use two different subclasses of > the controller. Then either test the class name, or have the subclasses > return a unique name or key (that's built into the subclass so you don't have > to set it in IB). _______________________________________________ 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
