Re: Trouble binding against transient Core Data property
Re: Trouble binding against transient Core Data property
- Subject: Re: Trouble binding against transient Core Data property
- From: Rick Mann <email@hidden>
- Date: Sun, 10 Oct 2010 21:52:35 -0700
On Oct 10, 2010, at 21:37:37, Quincey Morris wrote:
> 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"?
@dynamic shadowFrame;
"frame" is a transient Core Data property of Undefined Type, but it's an NSRect in the class file. Its implementation:
- (NSRect)
frame
{
[self willAccessValueForKey:@"frame"];
NSString* v = self.shadowFrame;
[self didAccessValueForKey:@"frame"];
NSRect nsR = NSRectFromString(v);
return nsR;
}
- (void)
setFrame: (NSRect) inVal
{
NSString* v = NSStringFromRect(inVal);
[self willChangeValueForKey:@"frame"];
self.shadowFrame = v;
[self didChangeValueForKey:@"frame"];
}
> 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?
VisualizationPlugIn* vp = ...;
NSView* view = vp.displayViewController.view;
[vp bind: @"frame" toObject: view withKeyPath: @"frame" options: nil];
I may not really fully understand bindings, in the sense that I don't know what you mean about NSView not having a "frame" binding. The docs imply that you can only call -bind:... on a binding that you've called -exposeBinding:... on, but someone at Apple told me that you only need to call -exposeBinding:... for IB's sake.
> 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.
Before I did this, it didn't save the view's frame. After doing this, it does, so something's working. I do have to set the frame once on load, though, otherwise it doesn't put the view in the right place (it just puts it in the default location). That, coupled with the undo behavior, makes me think the binding is "one-way," in that changing the view's frame does change the frame in the managed object, but a change in the managed object's underlying shadowFrame doesn't seem to make its way back to the view.
--
Rick
_______________________________________________
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