View Full Version : Learning Cocoa (ran into a problem)
Ok, so I finally decided I was going to sit down and try to learn cocoa. What better time than while learning java so I can try and see how confused I can get with different syntax's. Luckily since they are pretty different it hasn't been to hard though.
Well I guess my real problem is that my App doesn't work properly. Although I don't know why, and since I am just learning and mostly copying from the book (but I do understand most of it) I am at a loss without xcode throwing up errors at me.
I'm using the first edition of Cocoa Programming For Mac OS X by Arron Hillegrass. Yes it's 4 years old, I bought it when it was rather new and just never got around to learning :p.
The material doesn't seem to be online anymore so I figured I'd ask you guys. RaiseMan.zip (http://www.swigg.net/files/RaiseMan.zip) is my xcode folder.
Ok, so no errors, no warnings, everything seems fine, except when I put data into my NSTableView it doesn't stay. Making new rows and deleting them works, but data just doesn't stay in them. Is there something I missed or am over looking?
Edit: I'm sure it's something stupid, and something I just missed, but it's driving me crazy. Thanks for looking chucker!
Okay, three observations:
1) you're bundling a build folder, including an AppName.build one, which is 24.9 MBs worth of caches and such. Don't do that. :)
2) relatedly, when sending an app to others, you need to turn off ZeroLink, or it won't run for anyone but you. They easiest way is to switch to Deployment mode.
3) your version of Xcode is outdated.
Through some debugging, it turns out that:
1) the Person objects do get created and added to the employees array.
2) the Person objects do store their changed personName values.
3) they don't, however, store their expectedRaise values; those are always nil.
It appears
-(id)tableView:(NSTableView *)aTableView
objectValueForColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex
is never called, so the table view never actually attempts to fill the cells.
I guess my questions will be then…
Okay, three observations:
1) you're bundling a build folder, including an AppName.build one, which is 24.9 MBs worth of caches and such. Don't do that. :)
2) relatedly, when sending an app to others, you need to turn off ZeroLink, or it won't run for anyone but you. They easiest way is to switch to Deployment mode.
3) your version of Xcode is outdated.
1)so just don't include the build folder?
2)if one were to want to do that, he'd…?
3)does this matter for the time being? (but thanks, I will update later today)
Through some debugging, it turns out that:
1) the Person objects do get created and added to the employees array.
2) the Person objects do store their changed personName values.
3) they don't, however, store their expectedRaise values; those are always nil.
1)good
2)excellent
3)you may have answered this one
I guess my questions will be then…
1)so just don't include the build folder?
Right. Well, the build itself is okay (i.e., build/Release or build/Debug), but not the *.build folders underneath. Those are just huge and wasteful.
2)if one were to want to do that, he'd…?
Project -> Set Active Build Configuration -> Deployment.
3)does this matter for the time being? (but thanks, I will update later today)
No, no bearing on your problem. Just saying because my project file had to be upgraded, so it'd be incompatible.
Another observation: you did connect the dataSource, but not the delegate. However, that alone doesn't fix the problem. Still looking.
The mistake:
-(id)tableView:(NSTableView *)aTableView
objectValueForColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex
ought to be
-(id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex
Ok, looking through the code in this book, it doesn't look like that method ever gets called specifically. I kinda figured that the NSTableView called that from it's dataSource…which should be MyDocument. I didn't set any delegates, that is the very next portion of the chapter. Since they told me to build an run this, I assumed it should work fine, since they didn't say anything about it not working.
Ok, looking through the code in this book, it doesn't look like that method ever gets called specifically. I kinda figured that the NSTableView called that from it's dataSource…which should be MyDocument. I didn't set any delegates, that is the very next portion of the chapter. Since they told me to build an run this, I assumed it should work fine, since they didn't say anything about it not working.
See above; I found it. Works fine now.
Your like a golden god of knowledge in a fight with Brad for most informative member ;)
Thanks soooooo much! :D
Edit: Of course now I can say it wasn't my fault, stupidly long method names.;)
Your like a golden god of knowledge in a fight with Brad for most informative member ;)
More like a golden calf. Don't let him lead you astray! :lol:
More like a golden calf. Don't let him lead you astray! :lol:
You will not prevail! :devil:
*grabs popcorn, pulls up chair*
It's like the big nerd smackdown! :D
Mr Beardsley
2006-10-24, 14:47
Your like a golden god of knowledge in a fight with Brad for most informative member ;)
Thanks soooooo much! :D
Edit: Of course now I can say it wasn't my fault, stupidly long method names.;)
Get the latest Xcode, and turn on codesense. Unless of course you have a desire to get carpel tunnel syndrome. :D
Next time press Command+Shift+? to fire up the documentation.
Next time press Command+Shift+? to fire up the documentation.
How would that help? I misread text from a book, seems just as likely I'd do the same on my screen. Or are you just saying in general? I mean the biggest problem was I didn't know what was going wrong because I got no errors, I suppose I should have tried to figure out where it was going wrong better though.
Oh, I thought your book was out of date in this case. Apple seems to deprecate a lot of methods periodically, and the documentation always has the lastest info; Usually I just cut and paste the method declarations into my code, cause they can be quite long.
Also, you'll probably want to set the TableView's delegate to your Document class. Are you using the latest version of XCode? Cause it prompted me to upgrade your project file.
If you were unaware, there are loads of sample code in /Developer/Examples; specifically /Developer/Examples/Appkit.
Oh, I thought your book was out of date in this case. Apple seems to deprecate a lot of methods periodically, and the documentation always has the lastest info; Usually I just cut and paste the method declarations into my code, cause they can be quite long.
No, just my inability to read properly ;) I am going to cut and paste when I can, my book even mentions to do that because of their length and the possibility for error.
Also, you'll probably want to set the TableView's delegate to your Document class. Are you using the latest version of XCode? Cause it prompted me to upgrade your project file.
If you were unaware, there are loads of sample code in /Developer/Examples; specifically /Developer/Examples/Appkit.
Delegates is the very next part in this chapter, I just wanted to get my project working before I moved on to that…because it is supposed to. This book is old and for beginners (although it assumes knowledge of an OO language and C), so I'll be sure to check out all those examples to figure out how things work when I'm done with this. Thanks :)
I figured I'd just use this thread since it is still about me learning cocoa and while not a problem more of a question. If someone disagrees, they can split this into it's own thread, but I don't see that being necessary. So on with the question...
I'm trying to get a good idea of how memory management works in Cocoa. I was looking at an example in one of my books, and on two classes, in the allocation method it allocates (and initializes) an object and creates a static C type of an integer, or a float.
So at this point, there is an object and we'll say a float.
When the object's retain count reaches 0, it runs the dealloc method right? Well in both examples the dealloc method calls the release message on the object it created in the alloc method to say that it doesn't need it anymore. Well nothing is done with the float. When, or who deallocates the float? This seems like it would cause a memory leak unless it's taken care of at some point.
If you had function that made a million instances of that object and then deallocated them right away, wouldn't you have a million floats that were unused and inaccessible? From my understanding there is no automatic garbage collection like in Java or PHP, so those wouldn't be taken care of. Is there actually a simple garbage collection that gets rid static C types that are called in methods or classes when the function is done or the class is deallocated?
Mr Beardsley
2006-12-19, 12:08
Are you saying the objects you are creating have an instance variable of type float or int?
I don't quite understand where this static float or int value is coming from.
You declare an object with the following syntax.
@interface MyObject : NSObject
{
int number1;
float number2;
NSNumber *number3;
}
- (void) someMethod;
@end
When you call:
MyObject *obj = [[MyObject alloc] init];
The "alloc" call makes the allocator take a look at your object and figure out you need enough memory to hold an int, float, pointer, and the extra variables in NSObject. It then goes out to your memory and carves out a space to hold this object. The init portion does what it says it does and initializes the variables in your object. After all this, you have a nice shiny new object with a retain count of one, and taking up as much memory as its variables, and its superclasses variables need.
When you call:
[obj release]
The retain count goes to zero as you already know, and then it's dealloc method is called. You don't have to worry about cleaning up variables of type int, float, bool, etc. The space they claim in memory is part of the object, and that is reclaimed without any more work. Now the reason you have to call release on objects in your dealloc method is because your variable is just a pointer to another object in memory. In the examble above variable number3 is a pointer (pointers are just special ints), so while that pointer memory will get reclaimed, you need to tell the machine to also clean up that memory for that other object you were pointing to.
Hopefully this helps a little. I'm afraid I didn't do a good job explaining it.
Are you saying the objects you are creating have an instance variable of type float or int?
No, he's comparing C types with Objective-C objects. I.e., he's asking how float, int and such behave in terms of memory management as opposed to, say, NSTimer*.
Unless you specifically malloc a bit of memory to store your variable in the heap, then it goes on the stack and will be released when the subroutine exits.
It does make sense actually I believe.
So let me just work to get this straight to make sure I'm 100% on course. If you were to have a void method, that all it did was declare an integer and an NSString, when it finished running the integer would be freed, and the pointer to the NSString would be freed, but the actual object in the memory would still be there inaccessible and taking up space? And the same thing for a class, just on a larger scale? And the same thing for any subroutine in a program?
If that's not right I apologize, this whole memory management thing is relatively new to me and I want to make sure I really understand everything that is going on.
That memory would be accessible and reusable. The operating system takes care of that.
A memory leak is when you specifically allocate memory for something (whether its a simple variable or an object like NSString) and then forget to tell the program when you are finished using it.
The memory will then stay allocated (and unusable) until the program exits.
If you don't specifically allocate memory (like simply declaring an int or instantiating an NSString with @"") then when whatever routine you happen to be in exits, that memory is also released and reusable.
If you do specifically allocate memory (using malloc for that int, or alloc for the NSString) then it must be released specifically or it will only be released when the program exits.
That memory would be accessible and reusable. The operating system takes care of that.
A memory leak is when you specifically allocate memory for something (whether its a simple variable or an object like NSString) and then forget to tell the program when you are finished using it.
The memory will then stay allocated (and unusable) until the program exits.
If you don't specifically allocate memory (like simply declaring an int or instantiating an NSString with @"") then when whatever routine you happen to be in exits, that memory is also released and reusable.
If you do specifically allocate memory (using malloc for that int, or alloc for the NSString) then it must be released specifically or it will only be released when the program exits.
Alright, I'm pretty sure I'm clear on this, thank you very much everyone :)
vBulletin® v3.6.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd.