The problem in part is this:
Quote:
|
P.S. I was honestly hoping there were two or three lines I could cut and paste for the goes-ins and the goes-outs, and I could study those to see what's happening to extrapolate for future attempts.
|
I am frequently reminded of an apocryphal story when I read the URGENT posts or the PLEASE HELP posts. A friend calls me on the phone and says 'I just bought this gun. I've loaded it up with bullets but when I pull the trigger nothing happens. How do I make this gun shoot?' I helpfully tell him 'See that little button on the side of the gun? That's the safety. Push that button and the gun will shoot.' About five minutes later I get another call 'I just shot my foot. What do I do now?'
And then there's always the 'give a man a fish, teach a man to fish' thing. There are a lot of posters around here that don't know how to fish but are begging for fish, not lessons.
Anyone on this board who can answer more questions then he asks has gotten there by reading the docs, plus of course writing code. There's no shortcut. You must read at least some of the documentation in order to have any idea what's going on. Looking at the example code may be part of it but the docs are crucial. One problem with Apple's documentation is that there's not a clear guide to how to learn; there are mainly guides to technologies and reference material. There needs to be a list of what documents to read and in what order. There also needs to be a list of concepts that need to be understood. Cocoa memory management, target-action, how drawing takes place, the responder chain, how animation works, etc. If you don't know those things, sample code or code snippets won't help.
In general the guides are very helpful and I do recommend to everyone to start at the top of the list and read most or all of them. Not necessarily in one day but over time. And it's ridiculous to ask questions about tableviews without having read the tableview programming guide.
One other thing: on Apple's Cocoa-dev mailing list they have a policy that no one should explain Cocoa memory management. Instead all questions regarding that topic are to be referred to the documentation. The reason is that the documentation is complete, and more to the point, is correct. Having people explain Cocoa memory management on that mailing list just wastes space and is liable to give wrong info. It's a good policy.
It certainly sounds boring to be told to read 500 pages before writing any code. That's how I did it however. That's how anyone should.
