On May 23, 2014, at 19:34:10, Graham Cox <graham....@bigpond.com> wrote:
> If what you're really trying to do is to store a class in the nib such that > you can use that to instantiate the right kind of object for FO, I would say > that you're doing it wrong (™). What you probably want is some way in your > code to map a nib name, FO class and some other criterion together to know > which nib to load and which class of FO to make before attempting to load the > nib. I do this quite a bit. For example, I have an interface consisting of a > row of tabs, each containing a complete UI each loaded from its own nib. The > user can place the tabs in any order. When the app launches, it makes the > tabs (loaded from its own nib as well) and restores them to the previous > order, then for each tab, it looks up (based on an ID saved with the tab) > what FO class to make and which nib that wants, then goes ahead and makes the > FO, loads the nib and so the entire interface is reconstructed. At no point > is any hackery involved, but the loading mechanism is generic - the code that > maps my tab iD to a FO class is a simple class method that takes the one and > returns the other. The FO instance already knows the nib name (a further > mapping as such) because it supplies a -nibName property. In my case its a > NSViewController subclass so it already has this, but any object can be used > and designed to work similarly. Hmm. This is something I might look into doing. It would prevent us from having to load the nib twice, which would be good. Thanks. -- Steve Mills office: 952-818-3871 home: 952-401-6255 _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
