Re: Working through a problem...
john darnell wrote: I am attempting to follow these instructions, but whenever I do, when the cursor hovers over the table view control on the dialog the label that shows is NSTableColumn, and in the info panel the connected button remains grayed out and the message tableView must be of type NSTableView appears on the panel. How do I get IB to select the tableView instead of the columnView? I've always found the best way to deal with these nestings in IB is to use (permanently or temporarily) either List or Column View Mode. That way you can reveal the view hierarchy and see exactly what you are connecting. pg ___ 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 [EMAIL PROTECTED]
Re: @dynamic and Programmatic Access to Setters
On Apr 17, 2008, at 8:47 PM, Mike Rossetti wrote: Yes, that's my understanding. But according to the comments I mentioned in my earlier message, Core Data provides the implementations. And clearly it does since I can edit, save and restore the document. But you're doing all that via bindings, which uses KVC but doesn't require accessor methods. So it works does not imply that the accessors were synthesized. I'm just missing the 'magic' that tells me how to set/get a property being managed by Core Data. I think the problem is in your creation of the Tip NSManagedObject-- you can't simply call [[Tip alloc] init] and have it work. Create your object via [[NSManagedObject alloc] initWithEntity:@Tip insertIntoManagedObjectContext:[self managedObjectContext]] or [NSEntityDescription entityForName:@Tip inManagedObjectContext: [self managedObjectContext]] and it should work as expected. I'm pretty sure the property accessors are being synthesized; you're just not creating an object that can be recognized as the proper type to determine whether it responds to that selector. See http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdCreateMOs.html#//apple_ref/doc/uid/TP40001654-213474 for further information. pg ___ 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 [EMAIL PROTECTED]
Re: Syntax error when declaring an IBOutlet
On Mar 6, 2008, at 10:16 AM, Mark Teagarden wrote: I have another class, Display, that gives me the same error as the one in game.h - I've omitted it here for clarity. Basically, the mapview.h #import / IBOutlet is the only one that worked correctly. My questions are: 1. Why does identical code work in one file and not in the others? It's not identical. It's also not code--it's a preprocessor directive which is important because they have a tendency toward their own logic. I'll bet your World.h includes '#import Game.h' which creates an import cycle when imported from Game.h, but not when imported by WMapView.h. 2. Why should @class work when #import doesn't? Hillegass flat out says that the two are interchangeable. Where does he say that? I see the following in 2e Cocoa Programming: You could replace '@class PreferenceController;' with '#import PreferenceController.h'. This statement would import the header, and the compiler would learn that PreferenceController was a class. Because the 'import' command requires the compiler to parse more files, '@class' will often result in faster builds. which does _not_ call them interchangeable. Ignoring the fact that @class is faster than #import (a nice benefit in and of itself), it's a good rule of thumb to only use @class declarations for your project headers and only actually #import project headers from .m files, precisely to avoid these import cycles. pg ___ 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 [EMAIL PROTECTED]
Re: Syntax error when declaring an IBOutlet
On Mar 6, 2008, at 12:00 PM, Mark Teagarden wrote: Hi Paul, I'll bet your World.h includes '#import Game.h' which creates an import cycle when imported from Game.h, but not when imported by WMapView.h. Actually, it does. I was concerned that all of these objects needed outlets to each other, and that since (in my imperfect understanding) I had to import the headers of any object I wanted an outlet to point to, that there might be some a problem with all of those #imports. Since my understanding was that Obj-C uses #import instead of #include specifically to ensure that a header was only loaded once, I thought that would solve those types of problems. It does, but that's dependent on it successfully including it in the first place. It's a fair oversimplification to think of #import (and even #include) as simply insert contents of this file right here directives; once you hit an include cycle, though, you will never be able to generate the all includes inserted final output for compilation. You're not the first coder who has run into this, and you won't be the last. 2. Why should @class work when #import doesn't? Hillegass flat out says that the two are interchangeable. Where does he say that? I see the following in 2e Cocoa Programming: You could replace '@class PreferenceController;' with '#import PreferenceController.h'. This statement would import the header, and the compiler would learn that PreferenceController was a class. Because the 'import' command requires the compiler to parse more files, '@class' will often result in faster builds. which does _not_ call them interchangeable. Well, I am perfectly willing to admit that I was wrong I didn't intend it to be harsh or pedantic. Your statement just seemed like something rather out of place to put in the mouth of a respected author, so I was wondering where you found the flat out statement. but frankly I didn't see anything in there suggesting that they were NOT interchangeable, especially as there wasn't any discussion of differences between the two. In reading it, I felt like @class was simply introduced with no actual explanation of what it did. That could definitely be argued. It *is* a statement that makes more sense in hindsight. As far as I know, @class just flags that class name as a specialized version of 'id'. When it comes time to send messages to that object, you will need to have #imported the header to know its method signatures. But there are only rare instances when you need to know those signatures in the header file so defaulting to @class seems to be the safe way to go. pg ___ 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 [EMAIL PROTECTED]
