On Oct 10, 2010, at 18:55, Rick Mann wrote:

> I have a Core Data Entity called VisualizationPlugIn, and a class to go with 
> it. This Entity declares these properties:
> 
> NSString*     shadowFrame;
> NSRect                frame;          //  transient
> 
> and implements the getter and setter for frame as you would expect, 
> converting the rect to/from an NSString, and calling 
> will/didAccess/ChangeValueForKey.
> 
> When one of these is instantiated, it can also create an NSViewController 
> subclass and view hierarchy that gets added to a window. When that happens, I 
> programmatically bind the plug-in's top-level view's frame to the plug-in's 
> frame Core Data property. This all seems to work. If the user re-positions 
> the view hierarchy in the window, Core Data properly saves and restores that 
> frame.
> 
> But Undo doesn't work. If I move the plug-in's view around, I can see that 
> the context gets dirty (the close button in the window fills in), but if I 
> undo, the view isn't moved back, and the context doesn't get clean.
> 
> So I thought Core Data must be undoing the shadowFrame property, and no one's 
> getting notified. To the VisualizationPlugIn class, I added
> 
> + (NSSet*)
> keyPathsForValuesAffectingFrame
> {
>    return [NSSet setWithObject: @"shadowFrame"];
> }
> 
> But it never gets called.

There are some things you need to clarify here. You call the "frame" property 
transient, but do you mean a transient Core Data property, or just a non-Core 
Data property of the managed object subclass? Can you post code from the 
"frame" accessors that show how they relate to the "shadowFrame" property, and 
how the KVO mechanics are handled? Are you using the Core-Data-provided 
accessors (i.e. @dynamic) for "shadowFrame"?

What does "programmatically bind" mean? Are you saying you called [view 
bind:@"frame" toObject:something withKeyPath:@"frame" ...], or something like 
that? If so, this isn't going to work, because AFAICT NSView doesn't have a 
"frame" binding. Can you post your code for that, too?

Finding out why a 'keyPathsForValuesAffecting<Key>' method doesn't have the 
desired effect can be an extremely frustrating debugging exercise. Note that 
one reason why it won't get called is if nothing's actually observing the 
"frame" property.


_______________________________________________

Cocoa-dev mailing list ([email protected])

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]

Reply via email to