On May 23, 2014, at 19:28:32, Ken Thomases <k...@codeweavers.com> wrote:
> 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. That doesn't seem to be the case, because it does work. > 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: Like I said, it's some generic window loading code. We had hundreds of Carbon nibs, which we batch converted to Cocoa xibs. Rather than spend the months or even years it would've taken to rewrite all the code for all the windows to use proper Cocoa MVC type modeling, we instead leveraged the current *cross-platform* window handling code we already had and set the File Owner of nearly all the window xibs to be a generic NSWindowController subclass. We first create that generic controller, then it loads the nib. This worked for all the windows, but then I got to this one particular palette where I needed to have a custom subclass for the controller. -- 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
