Yes, Charlie, I know where the documentation is. My stupidity lies not in an inability to find the documentation, it lies in my inability to understand it.
I've read it over something like 10 times and I'm still not getting it. So if you could help, I'd sure appreciate it.
If the documentation isn't doing it for you, you might need to look at a basic Obj-C guide. Do you know how to get the value of an object's proerty? Or how to invoke an object's method by sending a message to it (as in [object message] syntax)?
If the answer is no, then have you tried going through some of the HelloWorld tutorials that are around?
If the answer is yes, then what exactly is it that is cofusing you?
Yes, I did the Hello, world tutorials and I'll be the first to admit that while my C is excellent, I'm reasonably objectionable about Objective-C.
I guess I don't fully _get_ how to extract data from a control, basically, which specific named item I'm looking for. I know I need to create a UIDatePicker pointer, but I guess it's not clear how to link the picker to a variable and vice-versa.
Undoubtedly, it's because of my newness to the Objective-C approach. I have spent a LOT of time reading and I've attempted a few things, but there's some conceptional leap I'm not making here.
I know you don't have to answer me, but I sure wouldn't mind some coaching, because I'm clearly missing something.
-- Raegis
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.
OK, there are two different approaches to get the property of a certain object
lets just go for a label
myLabel.text = thatLabel.text
That is the dot syntax. That allows you to get the property of a class. So what am I saying here? set myLabel's text property to be the same as thatLabel's text property.
there's also the messaging type:
myLabel.text = [thatLabel get:text];
I am not sure about the second one, as I don't use the messaging type at all.
The Dot Syntax basically means the property of that class
so...
myLabel
myLabel.text is the text of my label
myLabel.font is the font of my label
etc.
Understand?
When you are looking through a reference piece, it will refer to properties of an object. This is what its talking about.
It seems like every question people ask in the forums are responded to with, "please read the 1000s of pages of Apples documentation." You know the never ending documents that reference other documents. Questions are also responded to with, "Please look at the examples." You know, the complete examples that utilize every complicated methodology nested within one another.
If I have a problem with C#, it takes me seconds to find useful info on the web. If I have a question about objective c it takes for ever. This forum should be replaced with a single html document that says, "see the manuals idio!"
On behalf of me and all the new developers struggling to help you more seasoned developers make the iphone a great product, especially on the heals of Android, "Thanks!"
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.
Last edited by PhoneyDeveloper; 09-20-2008 at 10:21 AM.
Knowing how to use documentation is probably 80% of what helps me write my apps. That's the truth. The improvement of my code has come with the improvement of my ability to navigate the documentation.
In many cases, it's helpful to see some example code or to just be told the answer, but it's in my interest, the asker's interest, and in the interest of everybody who frequents this forum that we know how to look to the documentation.
I've seen a lot of people bash new developers for not looking at the documentation, and that sucks. Nonetheless, it's TRUE that being able to read and navigate the docs is an ESSENTIAL skill, and in this case that seemed to be the root of the user's problem.
Maybe we need to come up with a documentation guide. Some meta-documentation? Some tutorial creators like Nitrex88 do a great job of emphasizing the documentation rather than just pulling code out of a hat.
Is there a turtorial on UIDatePicker? I like the turtorials they tell in detail how to write the code to do those things needed. Then from there we use that in our own code to create wonderfull worlds of possabilitys. So is there one? I can get int char strings exectra from UItextFields I can display text. Yet I would like to see a turtorial on UIDatePicker if there isn't one can someone create one. I use code functioning code To learn and understand. In a sence to teach myself how to fish. Though I would need to be taught the best way to prepare and cook the fish.
It seems like every question people ask in the forums are responded to with, "please read the 1000s of pages of Apples documentation." You know the never ending documents that reference other documents. Questions are also responded to with, "Please look at the examples." You know, the complete examples that utilize every complicated methodology nested within one another.
If I have a problem with C#, it takes me seconds to find useful info on the web. If I have a question about objective c it takes for ever. This forum should be replaced with a single html document that says, "see the manuals idio!"
On behalf of me and all the new developers struggling to help you more seasoned developers make the iphone a great product, especially on the heals of Android, "Thanks!"
UIDatePicker question
Is there a turtorial on UIDatePicker?
Linear Mode
