Re: Bypassing Interface Builder

FROM : Boyd Collier
DATE : Wed May 14 19:34:25 2008

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_removed>)
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>