Re: NSTreeController - canonical example? (and other related questions)
Re: NSTreeController - canonical example? (and other related questions)
- Subject: Re: NSTreeController - canonical example? (and other related questions)
- From: "Pierce T. Wetter III" <email@hidden>
- Date: Fri, 24 Mar 2006 09:05:45 -0700
On Mar 24, 2006, at 8:17 AM, Jim Correia wrote:
Is there a canonical example of using NSTreeController (backed by
data from CoreData) ?
No. Most people have either given up on using bindings with
NSOutlineView, written their own NSTreeController, or in my case,
faked it with NSArrayController. (http://www.twinforces.com).
Some questions/observations:
- It seems the drag and drop issue has been beaten to death and
bugs have been filed.
- When using an array controller, a subclass can override -
arrangeObjects: to supply a different sort or filter mechanism. Is
there a similar mechanism for NSTreeController?
No.
- Starting with the OutlineEdit example, I modified the nib to
allow for multiple selection. When indenting multiple items (with
NSZombieEnabled=YES) I get the following at runtime:
2006-03-24 09:36:42.643 OutlineEdit[21424] Exception raised during
posting of notification. Ignored. exception: *** -[NSCFArray
objectAtIndex:]: index (1) beyond bounds (1)
2006-03-24 09:36:42.657 OutlineEdit[21424] *** -[_NSZombie
forward::] not overridden!
2006-03-24 09:36:42.722 OutlineEdit[21424] *** -[_NSZombie
forward::] not overridden!
Is this a bug in the sample or NSTreeController? Is there a
workaround?
Yes. No, not really.
- Any other gotchas to look out for?
Yes, lots.
#1: Don't change the tree...
Indenting multiple items changes the tree.
NSTreeController seems to really, really hate it when you rearrange
the tree. That seems to be a side effect of the way NSTreeController
is implemented as a tree of NSArrayControllers.
It's probably more friendly when you're not using CoreData because
the notifications go out one at a time so this didn't really become
apparent until after CoreData shipped. When you use CoreData a flurry
of notifications go out with processRecentChanges.
I was able to make it more stable by making sure I did a
processRecentChanges after each operation. However, that wasn't
always possible/convenient.
#2: Weird Omissions
There are some weird omissions. One would think there might be an
optional binding for "isExpanded". But there isn't, which means you
end up manually expanding the outline every time you open your document.
Filtering/sorting is another weird omission.
There's no "official" way to go from an outline item back to the
original object even though the item wraps the original object. This
is technically true of NSArrayController too that there's no API for
going from a row to an object and back again but [[controller
arrangedObjects] objectAtIndex: row] or [controller arrangedObjects]
indexOfObject: object] works pretty well.
#3: Both APIs?
I found that if I implemented both the data source and the binding
methods, that both sets of routines got called and different times
and that it was slightly more stable. For instance, to implement drag
and drop, you have to have methods that at least return nil.
Pierce
P.S.
I know Apple people read the list, and no doubt the
NSTreeController author reads the list. I just want to say that
despite my seeming kind of down on NSTC, I think the whole bindings
thing is cool, as is CoreData. I'm sure NSTC was a bitch to develop,
and I'm not surprised that perhaps the author got a bit blindsided
when everyone immediately merged CoreData with NSTC to implement
outlineviews. So I'm sure it will get fixed.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden