Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: Boyd Collier <email@hidden>
- Date: Wed, 14 May 2008 10:34:25 -0700
Andy,
Just wanted to congratulate you for your exceptionally clear and
succinct summary. If I'd had it when I first started using Interface
Builder, it would have saved me a lot of head scratching (and
occasional head-banging).
Boyd
On May 14, 2008, at 9:37 AM, Andy Lee wrote:
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden