Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: colo <email@hidden>
- Date: Wed, 14 May 2008 13:37:09 -0400
I second that to a T. Reading over all the messages now.
On Wed, May 14, 2008 at 1:34 PM, Boyd Collier
<email@hidden> wrote:
> 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
>
_______________________________________________
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