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]
Re: NSTreeController's arrangedObjects returning _NSControllerTreeProxy for KVC path?
On Thu, Jun 12, 2008 at 4:35 PM, Danny Price [EMAIL PROTECTED] wrote: 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? Good question. I would guess that not everything in the key path is KVC-compliant. For example, when the main window changes, do you receive KVO notifications to that effect from NSApp? Hamish ___ 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?
On Jun 12, 2008, at 08:35, Danny Price wrote: 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? It looks like you're assuming that a binding involves two objects and a keypath. In fact, a binding involves two objects and *two* keypaths. The documentation for the NSKeyValueBindingCreation protocol says: bind:toObject:withKeyPath:options: Establishes a binding between a given property of the receiver and the property of a given object specified by a given key path. - (void)bind:(NSString *)binding toObject:(id)observableController withKeyPath:(NSString *)keyPath options:(NSDictionary*)options Parameters binding The key path for a property of the receiver previously exposed using the exposeBinding: method. observableController The bound-to object. keyPath A key path to a property reachable from observableController. In your case, the two keypaths are arrangedObjects and name. It is not correct (in general) to expect to be able to jam them together into a single keypath and get the same result (or any result, as you saw). That's why there are two keypath fields to fill in when you set up the binding in IB. Confusingly, IB's display of the binding (e.g. controller.arrangedObjects.name) is a shorthand description meaningful for display purposes only. ___ 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?
On Jun 11, 2008, at 4:44 PM, Daniel Price wrote: As a test, I have an NSTreeController and an NSOutlineView within the same nib of a CoreData application (Leopard). If I bind the columns of the outline view to the controller directly within IB, it works as expected. eg: ShapeTC-arrangedObjects.name (where name is the attribute of the CoreData entity) Now if I add an outlet (and accessor) in MyDocument to that same controller instance in the nib and try to access the exact same data via the keypath: Application- mainWindow.document.shapeTreeController.arrangedObjects.name I get nothing in the view and this error in the log: [_NSControllerTreeProxy 0x1c73a0 valueForUndefinedKey:]: this class is not key value coding-compliant for the key name. I thought the whole shadow-object problem was fixed in Leopard?! Are these paths not equivalent and if so, why am I getting back this private object in the second case but not the first? I'm not sure what you mean by shadow-object problem. Just to explain something: NSArray and NSSet implement valueForKey to return an array (or set) of the results of doing valueForKey on each of their contained objects. You probably already know this. NSTreeNode doesn't do this. There's an enhancement request for this tho. Feel free to pile on. SO, [treeNode valueForKey:] doesn't do anything special right now. 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've also tried using arrangedObjects.representedObject.name but I get the same error. I need to figure this out because each of my documents maintains a tree controller (for the selection) but floating panel with an outlineview displays the contents of the current document. So there is only one outline view on screen. I used to do with with code and notifications and it worked but want to use bindings instead. Cocoa bindings are forcing me to put both the controller and the view within the same document nib which is no good for my application. 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. Why can't you put the view and the controller in the same nib? -- RONZILLA ___ 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?
On Jun 11, 2008, at 6:57 PM, Ken Thomases wrote: From the -[NSTreeController arrangedObjects] documentation: Returns a proxy root tree node containing the receiver’s sorted content objects. - (id)arrangedObjects Discussion This property is observable using key-value observing. Special Considerations Prior to Mac OS X v10.5 this method returned an opaque root node representing all the currently displayed objects. This method should be used for binding, no assumption should be made about what methods this object supports. 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. 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:. Charles___ 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]
