Cocoa mail archive
Re: Bypassing Interface Builder
FROM : Andy Lee
DATE : Thu May 15 17:11:24 2008
On May 14, 2008, at 10:33 PM, Johnny Lundy wrote:
> So it's the application instance. I don't understand what the
> application instance is. I can recite the documentation, which says
> it is a shared instance of NSApplication, also known as NSApp which
> is a global variable, none of which help me.
To me this indicates a very fundamental disconnect, because what you
recited explains NSApp perfectly. I can't tell where the disconnect
is, so I'll try to spell this out quickly. No offense intended here
-- I honestly don't know where the disconnect is.
You are writing a Cocoa application. There is a class called
NSApplication that represents the concept of a Cocoa application.
That's the purpose of a class in an object-oriented language, to
describe a *class* of things conceptually. Classes are usually named
for the thing they describe -- hence "NSApplication". NSApplication
handles the generic things that Cocoa applications do: managing the
main menu, managing the window list, dealing with mouse and keyboard
events, and so on.
Cocoa applications create objects (instances of classes). That's what
they do all day. Objects get created, they send messages to each
other, they get dealloc'ed. Thousands and thousands of objects, all
day long. In your application there is one special object that is an
instance of NSApplication. It represents the application itself. I
repeat: there is an object in your application that represents the
running application itself. There is only one such object, and it is
stored in a global variable called NSApp. That is what "application
instance" means.
> Why would someone bind to File's Owner? What specifically is it?
Unlike most other objects in a nib file (First Responder being the
exception), File's Owner is not a specific object. It is a
placeholder for an "owner" object that will be specified when the nib
file is loaded. You edit a nib file knowing that it will be loaded at
some point in your program, and *at that future time* the owner of the
file (hence "File's Owner") will be specified.
The file's owner gives your program access to the objects in the nib
file, through the connections you made to it in the nib.
I think newcomers sometimes assume that when you load a nib you get
some sort of NibObject that you can query to get at the objects in the
nib, perhaps using the name you assigned in the nib file. This is an
understandable assumption, but you don't get any such object. You
need to specify a file's owner for the nib (using the second argument
to +loadNibNamed:owner:), and you need to have constructed the nib so
it connects the file's owner to at least one of its objects.
--Andy
DATE : Thu May 15 17:11:24 2008
On May 14, 2008, at 10:33 PM, Johnny Lundy wrote:
> So it's the application instance. I don't understand what the
> application instance is. I can recite the documentation, which says
> it is a shared instance of NSApplication, also known as NSApp which
> is a global variable, none of which help me.
To me this indicates a very fundamental disconnect, because what you
recited explains NSApp perfectly. I can't tell where the disconnect
is, so I'll try to spell this out quickly. No offense intended here
-- I honestly don't know where the disconnect is.
You are writing a Cocoa application. There is a class called
NSApplication that represents the concept of a Cocoa application.
That's the purpose of a class in an object-oriented language, to
describe a *class* of things conceptually. Classes are usually named
for the thing they describe -- hence "NSApplication". NSApplication
handles the generic things that Cocoa applications do: managing the
main menu, managing the window list, dealing with mouse and keyboard
events, and so on.
Cocoa applications create objects (instances of classes). That's what
they do all day. Objects get created, they send messages to each
other, they get dealloc'ed. Thousands and thousands of objects, all
day long. In your application there is one special object that is an
instance of NSApplication. It represents the application itself. I
repeat: there is an object in your application that represents the
running application itself. There is only one such object, and it is
stored in a global variable called NSApp. That is what "application
instance" means.
> Why would someone bind to File's Owner? What specifically is it?
Unlike most other objects in a nib file (First Responder being the
exception), File's Owner is not a specific object. It is a
placeholder for an "owner" object that will be specified when the nib
file is loaded. You edit a nib file knowing that it will be loaded at
some point in your program, and *at that future time* the owner of the
file (hence "File's Owner") will be specified.
The file's owner gives your program access to the objects in the nib
file, through the connections you made to it in the nib.
I think newcomers sometimes assume that when you load a nib you get
some sort of NibObject that you can query to get at the objects in the
nib, perhaps using the name you assigned in the nib file. This is an
understandable assumption, but you don't get any such object. You
need to specify a file's owner for the nib (using the second argument
to +loadNibNamed:owner:), and you need to have constructed the nib so
it connects the file's owner to at least one of its objects.
--Andy
