On 06/11/2009, at 4:15 PM, Steve Steinitz wrote:
> I don't see anything wrong. In fact, it looks great. Does insertObjects::
> call insertObject:: so that one day, if you implement drag and drop for
> multiple items it will all work?
Good question, I haven't tested that but I will do so.
>
Hi Rob,
Rob Keniger wrote
What I've tried, which does seem to work, is overriding
-insertObject:atArrangedObjectIndexPath: and setting the parent
explictly if the item is being inserted at the top level:
...
Can anyone see anything wrong with this?
I don't see anything wrong. In fact, it
On 06/11/2009, at 7:35 AM, Steve Steinitz wrote:
> Fritz's idea looks much cooler (I might try it) but for a clumsier solution,
> have you written your own method to add new top-level items? I wonder if an
> IBAction like this would work:
>
> - (IBAction)
> addVisibleTopLevelItem: sender
> {
On 06/11/2009, at 5:38 AM, Fritz Anderson wrote:
> Here is what I did, for a small tree: My document keeps the root object as a
> KVO property -- I do not rely on a fetch.
>
> I declare classes for my tree-element entities. so I could implement a
> method, -(NSArray *)orderedChildren, to retur
Hi Rob,
On 5/11/09, Rob Keniger wrote:
as I add a new item to the top level it fails because the tree
controller does not assign the "invisible" root item as the
parent of the new item.
Fritz's idea looks much cooler (I might try it) but for a
clumsier solution, have you written your own
On 4 Nov 2009, at 9:15 PM, Rob Keniger wrote:
I have a Core Data model which consists of a simple tree of a
particular entity, which has two relationships, parent and children.
I have an NSTreeController managing the model, with an NSOutlineView
bound to the NSTreeController.
This works f
