Hey Doug, Thanks so much for your help. Un checking "Raises For Not Applicable Keys" did the trick.
Take a look at DragAndDropOutlineEdit.zip http://homepage.mac.com/matthol2/cocoa/page2/page2.html The author has an NSTreeController extension that makes accessing the "real" objects much easier. Would you be willing to share one of you proxy object classes as an example? Adam > My biggest gripe about outline views and tree controllers in 10.4 was that > it was difficult (impossible) to correlate items in the outline view with > their corresponding objects in the model in a (fully) supported way. This > is much better in 10.5; I haven't removed all the workarounds from my code > yet, but I am confident that I could and I will before I'm done. (I'm > converting my app to 10.5-only, which simplifies things.) > > I have been using mixed entities in an outline view for a while, and I > haven't found it to be a particular problem, even under 10.4. > > > NSTreeController does want a specific entity type if it's using Entity mode. > It's certainly the case that entities in the tree need to implement the > designated "children" and (optional) "Leaf" and "Count" keypaths, but they > can be different sub-entities of the designated entity type if its feasible > to go that route. > > If you bind an outline column to an property of the objects in the tree, and > some of your entities don't implement the property, you probably want to > turn off the "Raises [exception] For Not Applicable Keys" flag on that > binding. > > (As far as I know, I don't think the column bindings care if the entities > that it references a "fubar" property from are all from the same class, or > derive from a common class; it the entity implements "fubar", the binding > uses it.) > > In my case, I found it advantageous for a variety of different reasons to > put the tree controller in Class mode and create "proxy" objects (that all > derive from a base class that is the designated class for the tree > controller). The benefits of doing this is that my proxy objects can > implement any properties or behaviors that exist for the presentation in the > UI, independently of the Core Data entities that implement my model. So, > for example, my proxy objects implement a "displayName" property used in my > presentation, and derive those values in an entity-specific way without > pushing that presentation implementation down into my model objects. > > The proxy approach is a little more work, but it's not all that bad if you > remember to "use the Force" (the wonderful-ness of key-value observing). > > I hope this helps; if I can clarify please let me know. > > Doug K; > > > > On Sun, Mar 23, 2008 at 7:55 PM, Adam Gerson <[EMAIL PROTECTED]> wrote: > > > > > > > > > A general question: > > > > I have read a lot of discouraging posts on this list and out on the > > blogs about the trio of NSTreeController, NSOutlIneView and CoreData. > > Most of them come from the 10.4 era. Under 10.5 is this something that > > is working better now? > > > > A specific question: > > A lot of the NSTreeController, NSOutlIneView and CoreData example > > projects use a single entity that can be both a child and a parent of > > itself. If I want to model parent and child entities that have a > > completely different set of attributes (one is a group of objects, the > > other is the objects themselves) am I better of not using > > NSTreeController and CoreData? One problem I have already run into is > > that when you bind your entire OutlineView column to a > > NSTreeController entity it wants the parents and children to all have > > the same attributes. > > > > Adam > > _______________________________________________ > > > > 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/knowles.doug%40gmail.com > > > > This email sent to [EMAIL PROTECTED] > > > > _______________________________________________ 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]
