Cocoa mail archive
Re: Bypassing Interface Builder
FROM : Andy Lee
DATE : Wed May 14 18:37:14 2008
On May 14, 2008, at 11:35 AM, colo wrote:
> Hmmm. The letting it create the files in the nib file sounds fine for
> me. But what about the linking and configuring? It's just all
> reflected in code correct? The dragging a pipe to one object to the
> other that just all shows up in the .m right?
No. Nothing you do in Interface Builder modifies a .m.
A nib file contains descriptions of a set of objects:
(1a) what class each object is an instance of,
(1b) values for each object's attributes, and
(1c) how the objects connect to each other (through instance variables
called outlets).
When you edit a nib file in IB, you're specifying:
(2a) what objects should be in the nib (by dragging them from a
palette that lists the classes you want),
(2b) what values their attributes should have (by entering values in
an inspector), and
(2c) how they connect to each other (by control-dragging between them
and selecting which outlet of the from-object you want the to-object
to be).
When your application *loads* a nib, it:
(3a) instantiates the objects,
(3b) sets their attributes, and
(3c) connects them both to each other and to certain things in your
application (in particular, File's Owner, which you should definitely
understand).
As others have explained, IB does not generate code to do (3a), (3b),
and (3c). That's all taken care of by the Cocoa framework code that
loads the nib file.
There *is* a connection between your code and your nib, but it's in
the other direction. If you edit the outlets in the .h file for one
of your classes (outlets are designated with the IBOutlet keyword),
the nib file will update its understanding of the structure of that
class.
The "behind the scenes" of (3a), (3b), and (3c) are documented and
worth understanding; they touch on topics including init methods, KVC,
and the responder chain respectively. To be honest I can't recite all
the details offhand (like the exact rules for which init method gets
called), but I'm aware of the situations in which I should refer to
the documentation.
--Andy
DATE : Wed May 14 18:37:14 2008
On May 14, 2008, at 11:35 AM, colo wrote:
> Hmmm. The letting it create the files in the nib file sounds fine for
> me. But what about the linking and configuring? It's just all
> reflected in code correct? The dragging a pipe to one object to the
> other that just all shows up in the .m right?
No. Nothing you do in Interface Builder modifies a .m.
A nib file contains descriptions of a set of objects:
(1a) what class each object is an instance of,
(1b) values for each object's attributes, and
(1c) how the objects connect to each other (through instance variables
called outlets).
When you edit a nib file in IB, you're specifying:
(2a) what objects should be in the nib (by dragging them from a
palette that lists the classes you want),
(2b) what values their attributes should have (by entering values in
an inspector), and
(2c) how they connect to each other (by control-dragging between them
and selecting which outlet of the from-object you want the to-object
to be).
When your application *loads* a nib, it:
(3a) instantiates the objects,
(3b) sets their attributes, and
(3c) connects them both to each other and to certain things in your
application (in particular, File's Owner, which you should definitely
understand).
As others have explained, IB does not generate code to do (3a), (3b),
and (3c). That's all taken care of by the Cocoa framework code that
loads the nib file.
There *is* a connection between your code and your nib, but it's in
the other direction. If you edit the outlets in the .h file for one
of your classes (outlets are designated with the IBOutlet keyword),
the nib file will update its understanding of the structure of that
class.
The "behind the scenes" of (3a), (3b), and (3c) are documented and
worth understanding; they touch on topics including init methods, KVC,
and the responder chain respectively. To be honest I can't recite all
the details offhand (like the exact rules for which init method gets
called), but I'm aware of the situations in which I should refer to
the documentation.
--Andy
