Re: NSTableColumn value binding + keypath over a relationship
Re: NSTableColumn value binding + keypath over a relationship
- Subject: Re: NSTableColumn value binding + keypath over a relationship
- From: Stamenkovic Florijan <email@hidden>
- Date: Tue, 29 Sep 2009 18:27:37 -0400
On Sep 29, 2009, at 17:37, Bryan Matteson wrote:
Cannot remove an observer <NSTableBinder 0x177eb0> for the key path
"group.name" from <FSNote 0x1ad240>, most likely because the value
for the key "group" has changed without an appropriate KVO
notification being sent. Check the KVO-compliance of the FSNote
class.
Means exactly what it says. Somewhere you changed the value of a
group object without using KVC.
So, I am wondering, am I doing something wrong? It seems a
reasonable thing to do, binding a column's value to the
"arrangedObjects.relationship.attribute" key path, but maybe that
is not allowed?
It IS allowed, and the best way to go about it.
I have managed to work around this by binding the column to
"arrangedObjects.group", and using a custom value transformer. This
provides me with exactly the functionality I need, but I am still
wondering about the mechanics, and if I am doing something wrong.
This is probably not correct.
Check your outlineView's delegate methods where you have implemented
drag and drop. Somewhere along the way you are changing a value
without using the mutators. If you can't find it, post the relevant
code (i.e. the all drag-and-drop related code from the outline view)
and I'll help you spot it.
Bryan, Quincey,
Thanks for your replies. As for the "group.name" vs. "group.title"
that Quincy mentions, it's a typo in the email, not in the project.
As for messing up / not using KVO properly, I suppose that somehow I
am not, but I don't see how. I have read most of the CoreData docs and
have experience with similar technologies (WebObjects), and am fairly
certain I am not doing anything obviously wrong... Also what is
interesting is that I can
As for what Bryan mentions, that I am changing an attribute in a non-
KVO-compliant way, I do not think so. In that sense the message I am
getting is a bit misleading (also note that it says "...most likely
because...")...
Bryan, you say that my workaround is "probably not correct". Why? I
understand it is a long and not the-right-way, but the-right-way does
not seem to work for me at the moment.
As for the code in the outline view data source, here it is, I am not
changing the value without using the mutators, but perhaps it is
relevant:
- (BOOL)outlineView:(NSOutlineView*)outlineView
acceptDrop:(id <NSDraggingInfo>)info
item:(id)proposedParentItem
childIndex:(NSInteger)proposedChildIndex
{
NSPasteboard* pboard = [info draggingPasteboard];
NSArray* pboardTypes = [pboard types];
// Notes being dragged
if([pboardTypes containsObject:FSNoteIDURIsArrayPBType]){
// the group dragged to
NSManagedObject* group = [((NSTreeNode*)proposedParentItem)
representedObject];
// the URIs of Notes being dragged
NSArray* noteURIs = [NSKeyedUnarchiver
unarchiveObjectWithData:[pboard
dataForType:FSNoteIDURIsArrayPBType]];
NSUndoManager* um = [[group managedObjectContext] undoManager];
// relate the notes to the group dragged into
// do it as a single undoable op
[um beginUndoGrouping];
for(NSURL* noteURI in noteURIs){
// app delegate is the where the managed object URI -> managed
object reference logic resides
FSNote* note = (FSNote*)[appDelegate objectForURI:noteURI];
note.group = group;
}
[um endUndoGrouping];
return YES;
}
// accepting also other drag types (reordering of Groups contained in
the outline view), code that does that is here
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden