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: Ken Thomases <email@hidden>
- Date: Fri, 23 May 2014 19:28:32 -0500
On May 23, 2014, at 9:51 AM, Mills, Steve 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'm not sure that I follow what you're trying to do, but there's no File's Owner _in_ the NIB. The owner is provided from the outside when the NIB is loaded.
Specifying the class of the File's Owner in the NIB is a purely design-time thing. It's just to let IB know what outlets and action methods the object that will be provided at NIB load time should be assumed to have at design time. The class specified for the File's Owner in the NIB does not affect what gets allocated.
If you want to tell IB that the owner will be a given class, then just go ahead and do that. That will let you hook things up. Then, at runtime, you only need to provide an object which supports the necessary connection points. (Supporting action methods isn't actually required to get the NIB to load. Menu items for absent action methods will typically just be disabled. Buttons and the like will just do nothing.)
I doubt it's possible to learn the design-time-specified class from the objects of the loaded NIB. The technique you outline doesn't make sense. The window from the NIB won't have a controller if the controller was File's Owner and you passed nil for the owner when you loaded the NIB. You just told the NIB-loading machinery to connect the window to nothing.
In any case, it seems totally backward to me that you would choose a NIB name to load but not also choose the class of the object to own it. In fact, the best practice is to hard-code the NIB name into the controller class so that nothing else needs to know it. So whatever code of yours is currently choosing a NIB name should instead choose a class to load and own the NIB and instantiated it. So, for example:
@interface MyWindowController : NSWindowController
@end
@implementation MyWindowController
- (id) init
{
self = [super initWithWindowNibName:@"MyNibName"];
if (self)
/* … finish initializing … */;
return self;
}
@end
(… elsewhere:)
MyWindowController* myWindowController = [[MyWindowController alloc] init];
[myWindowController showWindow:self];
Since a window controller is so intimately tied to the NIB containing the window, it makes no sense to specify the two things independently. The MyWindowController class couldn't meaningfully be used with a different NIB, so its interface shouldn't allow a client to specify a different NIB name.
Regards,
Ken
_______________________________________________
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