HereAnd HereAnd last here
Originally Posted by wizard69
Exactly! Very frustrating to say the least. By the way I don't like the term code generator here as that is not exactly the case all the time.
Yes and try finding an explanation about how that is done.
Have you ever seen an explanation about HOW it works? Not what gets done but HOW. Everytime it is brought up the question is sweep under the rug.
In a nut shell that is the problem, the alternatives don't require this effort. For admittedly simple apps I find it much easier to do the interface I code. IB becomes a distraction or impediment to rapid development.
Pretty much show you how to use Outlets and Actions, how they work behind the scenes, and how Interface builder works. Took me 3 seconds on developer.apple.com to find.
It's pretty simple how it works. All the elements you use to make a GUI in IB are objects that get saved (or if you prefer serialized or some say freeze dried) in the .nib file. So let's say you have an NSButton in your interface. All of the information about it, like its size, text, position, and what method to call are saved in the nib file. When the nib file is loaded at runtime either automatically in the case of MainMenu.nib or if you do it explicitly for some other part of your interface, the runtime reads the nib and does an [[NSButton alloc] init] and then proceeds to set all the values on that NSButton. At runtime what you get is an NSButton object in memory with all it's attributes set and ready to go.
IBOutlet and IBAction are just macros in your code that get stripped out at compile time, but help Interface Builder better identify which parts of your code are destined to be wired up to the interface elements.
This differs from other approaches where when you create GUI elements actual compilable code for that element is generated in your project.
One of the good things about the IB way is that there is a great separation of View and Controller. In the IDEs that generated code for your elements people often times put their application logic right in the event handler for the control. The problem comes is what happens to all that application logic if you decide to delete the button? You would think that this wouldn't happen much, but you would be surprised at what you see some software engineers do.
All in all I much prefer the Interface Builder way of dealing with interfaces. The one pain point was keeping your custom classes from Xcode in sync with IB. It sounds like this will be a thing of the past in Xcode 4.
Long live ctrl + drag to wire up interfaces!