On 24 May 2014, at 12:51 am, Mills, Steve <[email protected]> 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 protected])
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 [email protected]
