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 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]
