On Apr 26, 2010, at 8:15 AM, ML wrote: > > How about a good book that explains what IB does, how to set delegates, first > responders, connect things up, etc
Here is an example of making a (simple) iPhone project all in code: http://www.trilithon.com/download/CodeOnly.zip There is a Cocoa Resource Programming Gude that covers Interface Builder issues. Setting delegates is done i the same way as making connections between any other pair of objects. You control-drag a connection from the object that should have the reference (pointer) to the object being referenced ( pointed at). In general, you hardly ever need to play with the responder chain. Connecting things together is as I described above in the context of delegates. > I think that misunderstanding prevents me from using IB as much as I really > should. An Interface Builder document (xib/nib) is simply a box full of serialised (freeze-dried, pickled, embalmed, archived, choose your metaphor) objects, with connections between them in such a way that they (should, at least) form a complete object graph. Objects in the XIB and on the design surface during design and construction time are live objects, exactly the same as if you had created them programatically. When you change attributes using Interface Builder's Attributes Inspector, Interface Builder is sending messages to those objects, just as if you had programatically sent those messages from code. So in the end, there is nothing really magic about Interface Builder. At application run time, when the time comes to load the NIB using the Bundle Loader, the important tasks that the loading process performs are (1) unarchiving the archived objects into memory to form an object graph, and (2) using the information provided in File's Owner plus the already instantiated 'owner' object in the existing application's object graph to join the two object graphs together. There are various (opinionated) factions on the subject of whether or not to use Interface Builder. The choice is entirely yours. That said, if and when the time cones to locali[sz]e your application, you will suddenly discover that Interface Builder can and will save you tons of otherwise laborious drudge work. I live to a certain degree in both camps. Doing a iPhone Tab Bar application via Interface Builder I find to be laborious, error-prone, and klunky. But instead of writing loads of code, I write an XML description of the starting architecture in a plist, and dynamically instantiate everything at launch time in a fairly compact loop. In applications where I need a lot of fiddly and finicky layout, I use Interface Builder for what it's good at. Cheers, . . . . . . . . Henry _______________________________________________ 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 arch...@mail-archive.com