Re: Problem overriding newObject in NSTreeController
Re: Problem overriding newObject in NSTreeController
- Subject: Re: Problem overriding newObject in NSTreeController
- From: mmalcolm crawford <email@hidden>
- Date: Wed, 22 Jun 2005 17:59:27 -0700
On Jun 22, 2005, at 5:13 PM, Michael McCracken wrote:
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'm not sure why you can't customise addChild:?
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?
Again I'm not sure in what sense you mean "messy"?
Within the method you can find out what is your (the controller's)
current selection; determine on the basis of that what is the entity
of which you want to create a new instance; create a new instance of
that entity (insert it into the same managed object context as the
current selection), and add the new instance to the relationship.
This isn't really messy, unless you have a peculiarly baroque way of
determining the appropriate entity?
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.
I *think* issues with drag and drop etc. should be irrelevant to add:
and addChild:, although there may be something I'm overlooking in
your requirements.
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