I tightened up the code a bit:
#Obj-C version: - (id)initWithContentsOfURL:(NSURL *)nibFileURL
nib_file = NSNib.alloc.initWithContentsOfURL NSURL::fileURLWithPath(@@NibPath)
#Obj-C version: -
(BOOL)instantiateNibWithOwner:(id)ownertopLevelObjects:(NSArray
**)topLevelObjects
#The Ruby bridge puts
On Dec 5, 2009, at 3:46 PM, DeNigris Sean wrote:
>> 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
> 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
On Dec 4, 2009, at 9:47 PM, DeNigris Sean wrote:
I'm trying to unit test a view class. As it is very thin (just
delegates all work to the controller), all I want to check is that
my connections (e.g. outlets and actions) are hooked up correctly.
I've been trying to:
1. Create an instance o
On Dec 4, 2009, at 7:47 PM, DeNigris Sean wrote:
> I'm writing a RubyCocoa app, but my question is on the Cocoa API...
>
> I'm trying to unit test a view class. As it is very thin (just delegates all
> work to the controller), all I want to check is that my connections (e.g.
> outlets and acti
Hi list!
I'm writing a RubyCocoa app, but my question is on the Cocoa API...
I'm trying to unit test a view class. As it is very thin (just delegates all
work to the controller), all I want to check is that my connections (e.g.
outlets and actions) are hooked up correctly.
I've been trying to
