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