Re: Problem overriding newObject in NSTreeController
Re: Problem overriding newObject in NSTreeController
- Subject: Re: Problem overriding newObject in NSTreeController
- From: Michael McCracken <email@hidden>
- Date: Wed, 22 Jun 2005 17:13:14 -0700
OK, I am using Core Data, and I have the treecontroller set to entity
mode, using my abstract "Container" entity. The only binding that is
set on the controller is the MOC, and there is a predicate for
isRoot==1.
What happens in this situation is that -add: uses newObject, which I
haven't changed except for an nslog, *and* it creates entities that
are the same kind as the selection - not the entity the controller is
set to, but one of the children entities of that abstract entity.
Meanwhile, -addChild: doesn't use newObject, and creates instances of
the abstract parent entity.
I guess one or the other is unexpected. It seems that add: already
does what I want, so I don't need to customize it, while the one I
can't customize is the one I want to.
I can get the behavior I need for now by just not using the
controller's add or addChild, but I'm concerned that I'll get into
trouble later (eg, with drag and drop) if I do that, and I'd rather
not fight AppKit.
Is it the case that overriding addChild isn't as messy as I expect,
especially if I'm only expecting to use it with core data?
Thanks for digging through this with me,
-mike
On 6/22/05, mmalcolm crawford <email@hidden> wrote:
>
> On Jun 22, 2005, at 3:58 PM, mmalcolm crawford wrote:
>
> > There are different code paths depending on whether or not the
> > content uses Core Data. If you're not using Core Data, then
> > newObject is called [by both add: and addChild:]. If you are using
> > Core Data, then the controller tries to create a new object of the
> > appropriate entity, depending on the relationship in the current
> > selection.
> >
>
> To clarify: (as empirically determined) the controller's
> implementation of addChild: does not use newObject if the content is
> specified as an entity.
>
> mmalc
>
> _______________________________________________
> 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
>
--
Michael McCracken
UCSD CSE PhD Student
San Diego Supercomputer Center
http://www.cse.ucsd.edu/~mmccrack/
_______________________________________________
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