Re: Figuring out the file's owner class
Re: Figuring out the file's owner class
- Subject: Re: Figuring out the file's owner class
- From: Graham Cox <email@hidden>
- Date: Sat, 24 May 2014 10:34:10 +1000
On 24 May 2014, at 12:51 am, Mills, Steve <email@hidden> wrote:
> We have some generic window loading code that must instantiate the window controller first, then calls initWithWindowNibName: on that. This made it impossible to provide a subclass of our generic window controller subclass in the xib, but now we need to do this. Since NSNib doesn't have a method or property for the file's owner, the best way I know of to get this is to look for the window in the nib (see function below), gets its controller, get the controller's class, then release the window so we can create things in our "normal" way.
>
> If there some better way to get the file's owner class?
I've read this through several times and am unclear what you're really trying to do here. But of course you can set the class of File's Owner in the nib - just select the File's Owner icon, and in the info panel set its class. That's exactly how you're supposed to do it. It doesn't matter that you instantiate the File's Owner before loading the nib - that's also normal - setting FO's class in the nib doesn't actually do anything except inform IB what class to expect there, so that any properties, outlets, etc can be pre-connected in the nib.
You are also not required to have FO actually represent the window controller, though typically it is. It could be any object at all, and you could have the window controller as another object in the nib, class set as you wish, and connected as you wish. All that matters is that the code that loads the nib and the structure of the nib itself are in agreement about the object graph to be found there.
It's very unusual to have to iterate over the top level objects, though I believe that nowadays if you really have to do this, you can look for a specific identifier property that you've set in IB (as opposed to the default 'automatic' identifier assigned to each object) and that allows you to find the one of interest. But since FO isn't actually an object in the nib, its not going to be among the top level objects anyway - you are supplying that object when you load the nib, so you already know its class.
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.
pseudocode:
- (id) makeControllerAndLoadNibForID:(NSString*) identifier
{
Class filesOwner = [[self class] filesOwnerClassForID:identifier];
id controller = [[filesOwner alloc] init]; // loads the nib by calling -initWithNibName:owner:, passing self as owner
return [controller autorelease];
}
I feel sure you must know this already, so having to point it out means that I've likely misunderstood the question.
--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