Re: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
In general, you should not treat NSController-derived classes as holders of data. They are specifically for binding to. Since the shapeTreeController gets its content by binding to something else, why don't you just directly access that something instead of trying to go through the controller? In other words, access your model, not your controller. The controller's content is an NSMutableArray in the document and the nodes are CD entities with parent and children relationships. However I also need the selection (which persists per-document) and the only place I can get that from is the controller. ___ 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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
I'm not sure what you mean by shadow-object problem. I'm referring to the 'brick' object returned by the tree controller in 10.4 which required hacks via a category and the private 'observedObject' function. In Leopard, [treeController arrangedObjects] returns a proxy object (the same way that NSArrayController does for its arrangedObjects method). The proxy object currently isn't a subclass of NSTreeNode. Feel free to pile on bugs for that one too. BUT, the treeController's arrangedObjects proxy DOES respond to two NSTreeNode methods - - childNodes - descendantNodeForIndexPath (I'm typing these from memory, so please check these with the .h) Incidentally, I believe the documentation is wrong about this. The header is right. NOW, you can iterate over the tree yourself, going from childNode to childNode getting valueForKeyPath@:representedObject.name. I tried that, as described (in IB with a keypath) and got the same error. I'm not sure I understand what you want to end up with. You have a treecontroller in each document and want only the frontmost document's treecontroller to drive an app global outline view? You should be able to rebind the outlineview when the frontmost document changes. Yes that's exactly what I'm trying to do :) Why can't you put the view and the controller in the same nib? Because that's what Cocoa is forcing me to do (and the reason I suspect that single-window apps are increasingly common) but that's no good for the design of my application. ___ 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: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
That's what I used to think, too, until someone on this list pointed out to me that this snippet is in the header for NSTreeController: // proxy for the root tree node responds to -childNodes and -descendantNodeAtIndexPath:(NSIndexPath *)indexPath - (id)arrangedObjects; So whereas prior to 10.5 this method returned an opaque root node, in Leopard you at least are promised that it will respond to -childNodes and -descendantNodeAtIndexPath:. So the object is single-level tree where each leaf is the actual item selected? What I don't understand is why the same binding returns a different object in two cases? Why don't get this proxy object when I bind the view directly to the controller? ___ 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]
Core Data entities within a single context across multiple nibs
I'm having some trouble managing and editing Core Data entities within a single context across multiple nibs. In my main document nib, I have an NSTreeController with it's content binding set to an NSMutableArray within the document class. I can bind an outline view to this, and some other fields and it all works great. The controller uses the following path for the Managed Object Context (rather than using Files Owner directly so I can use the same path everywhere) NSApplication.mainWindow.document.managedObjectContext and the content array is NSApplication.mainWindow.document.shapes Now I have an inspector panel in a seperate nib with an identical NSTreeController with identical paths set, and some fields bound to the attributes of the current 'selection'. If I a add an entity to the main window, the fields in the inspector sometimes update, and sometimes don't. There's doesn't seem to be any patten to it. Changing the selection has no effect and there are no relevent messages in the console. I used to handle all this in code with notifications but I would like to get it working with CoreData bindings. Unless I'm mistaken, there is only one per-document context being shared here and both controllers point at the same thing. So if I alter the context with one, that change should immediately be apparent in the others, no? This all works great in a single-nib app. Any help appreciated. ___ 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]
