I second that to a T. Reading over all the messages now.
On Wed, May 14, 2008 at 1:34 PM, Boyd Collier <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) >> >> 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/bcollier%40sunstroke.sdsu.edu >> >> This email sent to [EMAIL PROTECTED] >> > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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/colo0logo%40gmail.com > > This email sent to [EMAIL PROTECTED] > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
