> 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]
