In <BB41D317.AE89%spamguyihate.spammers.com> Will Oram wrote:Here's how to think of it. You never *have* to instantiate in a nib; in> Here's a general question. When should I instantiate, and when should
> I not? Is an instantiated object necessarily a controller? Should I
> even *have* that many instatiations in a nib?
fact, you never *have* to use a nib. Everything the nib does, you can do
in code. You could make a window from scratch, put subviews into it, and
hook up references and targets. However, if there is only one of
something in a nib and it's easier to let the nib do the instantiation
for you, and you don't mind the memory overhead of having this thing
exist as long as the nib is open, then go right ahead.
Well, that's what the file's owner is for. That is NOT an object> In fact, as it stands, if an object isn't instantiated, I don't know
> how to use it. With instantiation, you create methods/outlets and hook
> 'em up to interface objects -- easy. With non-instantiation, I can
> create outlets and methods, but I don't know what to do to make other
> objects act on them.
instantiated in the nib; it's just a proxy for something instantiated
elsewhere (typically the NSApplication or an NSWindowController). You
can make connections between that and anything else in the nib, so as
long as you can get a reference to that instance in code, you have the
But there are many, many other ways for objects to relate besides
through connections drawn in the nib. A view has superviews and subviews.
A view has a window. A thing may have a delegate, a target, a formatter.
These are all relationship that can be set in code and, just as
important, may be fetched in code. Finally, remember that you often
don't need a direct connection in order to send a message; you can use a
nil-targeted action or a notification. m.
matt neuburg, phd = [email]matttidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
Subscribe to TidBITS. It's free and smart.