Maybe you could set an NSUserDefaults value, that is being read in
+initialize/-init of the "view" class to create your settingsname
there...
-- Reinhard
Am 06.05.2010 um 03:41 schrieb Graham Cox:
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/macmeideln%40googlemail.com
This email sent to macmeid...@googlemail.com
_______________________________________________
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
