> Really, the external name table is for referring to objects in nibs, rather
> than pushing objects into nibs.
Thanks. That's what I wanted to know - I thought the docs suggested maybe you
could pass objects in (other than owner)
> Furthermore, from your further description it sounds like what you’re
> referring to as a “view” is actually a subclass of NSWindowController; it
> knows how to load a nib file already, so you should just leverage that rather
> than try to do it all yourself by hand.
Thanks again. It's an "ultra-thin gui" a-la Dave Astels' TDD: A Practical
Guide (originally Mike Feathers' Humble dialog). There is another controller
class that handles all the logic. This class just delegates the actions and
outlets from Cocoa, so from my app's perspective, it's a view, but from cocoa's
perspective, it's a controller. It think it should be just an NSObject (that's
what I've seen in all the books and there's only one window in my app). I made
it an NSWindowController in the process of trying to get it to load the nib
(which is only for testing) and forgot to set it back. Is there a reason to
keep it an NSWindowController?
I ended up with the following that loaded the nib successfully in the test:
NSApplication.sharedApplication
top_level = []
context = NSDictionary::dictionaryWithObjects_forKeys [NSApp, top_level],
[NSNibOwner, NSNibTopLevelObjects]
@@NibPath = "/path/to/MainMenu.nib"
OSX::NSBundle::loadNibFile_externalNameTable_withZone @@NibPath, context,
NSApp.zone
objects = context['NSTopLevelObjects']
view = objects.find { |obj| obj.class == object_type }
Sean DeNigris
[email protected]
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
