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 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]
