[groupsArray addObject:[node groupDescendants]];

rather read:

[groupsArray addObjectsFromArray:[node groupDescendants]];

Thanks, M.

There could be an issue with incorrect bindings. What I did in my example was to bind the NSValueBinding (“Value” in IB) of the table column to the tree controller’s arrangedObjects.displayName keyPath. My first thought is that, as the NSValueBinding of the NSButtonCell refers to the on/off state of the button, the binding is turning them on if the bound string is not nil.

Not sure how you would solve this one as there are two values you need to consider here, the value and the label. This should be possible with bindings, but I’d do a long search on the cocoa-dev mailing list from Apple, this kind of thing comes up regularly.

Glad it helped. As for the benefit, it’s mainly to help you ensure that changes to the model are automatically pushed to the tree controller without you having to intervene or tell the outline view to reload data, saving you the maintenance of the application logic in, what is likely, a fairly integral part of your app. Each time you add a node object to the managed object context (in the full-blown core data version I’ve also got on this blog) the tree controller will update its display.

It doesn’t come without its caveats, which were the main reason for writing this post. When I wrote it there were no decent tutorials for the Leopard world that included the new NSTreeNode, which I saw as the saving grace of this whole setup.

You save yourself writing the datasource methods, which is a both a blessing (not having to write them) and a curse (having to deal with the tree controller’s representation of things).

So really my answer, is “not much, until I’d written all this” but it was a challenge to get it working. What’s probably more important are the extensions on NSTreeNode themselves, which allow to to properly navigate the content of the tree.

Bindings with NSTreeController also allow you to remove a lot of other code, for example that which needs to know when the selected objects in the tree change. Without the tree controller you have to rely on notifications, which (in my experiments) are only sent for user-side updates. If you use bindings or simple KVO on the NSTreeController’s selectedIndexPath property then you save yourself some debugging hassle.

Have you tried using table view’s with and without NSArrayController? You see the same reduction in code when you do adopt bindings in those cases, too/

Sorry if this has been a bit waffling, I’m way too tired.

Jon

I am wondering if there is a benefit to using a tree controller rather than just handling the NSOutlineView groups/leafs using the objects.

What does binding bring to the table that not using them doesn’t?

Sorry I’m afraid I don’t have anything prepared. The example app on katidev uses an NSOutlineView, so I’d just create an NSTreeController in that NIB and connect it up as I’ve described in this article.

Jon

Sorry I’m afraid I don’t have anything prepared. The example app on katidev uses an NSOutlineView, so I’d just create an NSTreeController in that NIB and connect it up as I’ve described in this article.

Jon

do you have a sample Application which combines your ESNode and XSController?

Take care…