Programmatic Binding
I have an issue that has me absolutely stumped. I have a custom view
using a custom layer. When 'bind:toObject:withKeyPath:options:' is
called after 'setView' the binding works. When it is called before
'setView' the binding does not work.
// MyCustomView (this version works)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer setView:self];
[layer bindFoo]; // bind works
...
}
// MyCustomView (this version does not work)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer bindFoo]; // bind does not work
[layer setView:self];
...
}
// MyCustomOpenGLLayer
@property (retain) MyCustomView *view;
@synthesize view;
- (void)bindFoo
{
[self bind:@foo
toObject:[NSUserDefaultsController sharedUserDefaultsController]
withKeyPath:@values.foo
options:nil];
}
Any ideas why the first version works but not the second?
--Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 8:17 AM, Richard Somers wrote: I have an issue that has me absolutely stumped. Correction and additional information. MyCustomOpenGLLayer should be MyCustomLayer. MyCustomLayer does not implement 'bind:toObject:withKeyPath:options:' so the standard framework version of this method is used. --Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 07:17, Richard Somers wrote:
I have an issue that has me absolutely stumped. I have a custom view using a
custom layer. When 'bind:toObject:withKeyPath:options:' is called after
'setView' the binding works. When it is called before 'setView' the binding
does not work.
...
- (void)bindFoo
{
[self bind:@foo
toObject:[NSUserDefaultsController sharedUserDefaultsController]
withKeyPath:@values.foo
options:nil];
}
What is foo?
What does not work mean?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding
Are you exposing the binding first?
+ (void)exposeBinding:(NSString *)binding
Thanks,
Chaitanya Pandit
Chief Architect
Expersis Software Inc.
On May 18, 2010, at 7:47 PM, Richard Somers wrote:
I have an issue that has me absolutely stumped. I have a custom view using a
custom layer. When 'bind:toObject:withKeyPath:options:' is called after
'setView' the binding works. When it is called before 'setView' the binding
does not work.
// MyCustomView (this version works)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer setView:self];
[layer bindFoo]; // bind works
...
}
// MyCustomView (this version does not work)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer bindFoo]; // bind does not work
[layer setView:self];
...
}
// MyCustomOpenGLLayer
@property (retain) MyCustomView *view;
@synthesize view;
- (void)bindFoo
{
[self bind:@foo
toObject:[NSUserDefaultsController sharedUserDefaultsController]
withKeyPath:@values.foo
options:nil];
}
Any ideas why the first version works but not the second?
--Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/chaitanya%40expersis.com
This email sent to chaita...@expersis.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 9:21 AM, Chaitanya Pandit chaita...@expersis.com
wrote:
Are you exposing the binding first?
This is completely unnecessary.
--Kyle Sluder
+ (void)exposeBinding:(NSString *)binding
Thanks,
Chaitanya Pandit
Chief Architect
Expersis Software Inc.
On May 18, 2010, at 7:47 PM, Richard Somers wrote:
I have an issue that has me absolutely stumped. I have a custom
view using a custom layer. When
'bind:toObject:withKeyPath:options:' is called after 'setView' the
binding works. When it is called before 'setView' the binding does
not work.
// MyCustomView (this version works)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer setView:self];
[layer bindFoo]; // bind works
...
}
// MyCustomView (this version does not work)
- (void)awakeFromNib
{
layer = [[MyCustomLayer alloc] init];
[layer bindFoo]; // bind does not work
[layer setView:self];
...
}
// MyCustomOpenGLLayer
@property (retain) MyCustomView *view;
@synthesize view;
- (void)bindFoo
{
[self bind:@foo
toObject:[NSUserDefaultsController sharedUserDefaultsController]
withKeyPath:@values.foo
options:nil];
}
Any ideas why the first version works but not the second?
--Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 10:04 AM, Quincey Morris wrote: What is foo? What does not work mean? Foo is an int. Does not work means foo is never updated with the value in the user defaults. On May 18, 2010, at 10:21 AM, Chaitanya Pandit wrote: Are you exposing the binding first? No, but I agree with Kyle Sluder that this is not relevant. --Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 12:02, Richard Somers wrote: Foo is an int. sigh If you want an answer, you're going to have to be a bit more forthcoming with information. Is foo an instance variable or a property? If instance variable, what's the value of accessInstanceVariablesDirectly for its class? If a property, is there an @property declaration, and how are its getter and setter defined? Does not work means foo is never updated with the value in the user defaults. Have you verified whether setFoo: is never called, or whether it's called with the wrong value? Is the setter called when you subsequently change the user default value that foo is bound to? How do you know that the user default value is correct? Just knowing that foo has the wrong value at some point isn't much help in tracking down the problem. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 1:40 PM, Quincey Morris wrote:
sigh If you want an answer, you're going to have to be a bit more
forthcoming with information.
Is foo an instance variable or a property? If instance variable,
what's the value of accessInstanceVariablesDirectly for its class?
If a property, is there an @property declaration, and how are its
getter and setter defined?
Have you verified whether setFoo: is never called, or whether it's
called with the wrong value? Is the setter called when you
subsequently change the user default value that foo is bound to? How
do you know that the user default value is correct? Just knowing
that foo has the wrong value at some point isn't much help in
tracking down the problem.
Thanks for being patient and helpful. Foo is an ivar with a getter and
setter, so that makes it a property.
@interface MyCustomLayer : CAOpenGLLayer
{
@private
int _foo;
}
@end
@implementation MyCustomLayer
- (int)foo
{
return _foo;
}
- (void)setFoo:(int)foo
{
_foo = foo;
// When foo is changed update the size of the layer.
CGFloat size = (2 * foo) + 1;
[self setFrame:CGRectMake(0.0, 0.0, size, size)]; // This is
where the problem occurs!
}
@end
I have verified that the setter 'setFoo' is being called in all cases
so that is not the problem as I originally thought.
In 'awakeFromNib' when 'bindFoo' is called before 'setView' the layer
frame is set but never actually changes to the set value! So the
problem is not one of binding but of layer initialization.
The user default value of foo is 8 which means the first time through
'setFoo' sets the layer frame width and height to 17. But the layer
frame width and height never actually get changed but are a value of 1
(not sure where that comes from) which for me is a non-operational
layer and causes other problems.
If the user defaults changes and sets the value of foo a second time
(after awakeFromNib) then the layer frame width and height gets
properly set and all is well.
So to recap.
// In awakeFromNib this works. Layer frame is set to correct
value.
layer = [[MyCustomLayer alloc] init];
[layer setView:self];
[layer bindFoo];
...
// In awakeFromNib this does not work. Layer frame does not
properly set.
layer = [[MyCustomLayer alloc] init];
[layer bindFoo];
[layer setView:self];
...
I have also tried the following.
layer = [[MyCustomLayer alloc] init];
// Do something else here. But the only thing so far
// that works is [layer setView:self]
[layer bindFoo];
...
Note that I have also tried changing foo from an int to a NSNumber but
it makes no difference. The layer initialization is very
temperamental. Originally the layer was in a nib which worked fine. I
have been refactoring and cleaning up and moving things out of the nib
that do not really belong there. That is when I ran into this problem.
It makes me a little nervous that the layer initialization is so
temperamental.
--Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 15:21, Richard Somers wrote: I have verified that the setter 'setFoo' is being called in all cases so that is not the problem as I originally thought. In 'awakeFromNib' when 'bindFoo' is called before 'setView' the layer frame is set but never actually changes to the set value! So the problem is not one of binding but of layer initialization. The user default value of foo is 8 which means the first time through 'setFoo' sets the layer frame width and height to 17. But the layer frame width and height never actually get changed but are a value of 1 (not sure where that comes from) which for me is a non-operational layer and causes other problems. It's a bit hard to tell, because there's too much getting tested at once here, but it looks like you have 2 possible problems: 1. Setting the frame on a layer that doesn't have a view yet doesn't do anything useful. This happens because the 'bind:...' invocation is going to cause the setter to be invoked initially, and in your non-working case, the view's layer hasn't been set yet. and/or 2. The setter is getting called with a value of 0. That would set the width and height of the layer to 1. There may a third thing going on too, but the other things are in the way. You need to set a breakpoint in the setter and examine to backtrace (call stack) to figure out when and why it's being called, I think. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding
On May 18, 2010, at 4:44 PM, Quincey Morris wrote: 1. Setting the frame on a layer that doesn't have a view yet doesn't do anything useful. This happens because the 'bind:...' invocation is going to cause the setter to be invoked initially, and in your non-working case, the view's layer hasn't been set yet. Oops, I made an error. There was a dependency between the view and the layer initialization. Only took me about 1.5 days to find it. It is amazing how sometimes you can be blind to your own code. Without help from this forum I may have never found the mistake. I think my debugging skills have improved and so I want to say thanks for the help. --Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Programmatic Binding KVC KVO
I have a managed object context with two attached NSObjectControllers in entity mode. Both controllers control the same entity. managed object model nib 1 controller user interface bind in interface builder nib 2 controller user interface (custom view) bind in code programmatically Nib 1 works. Entity changes produce by the user interface show up in the managed object model and in the custom view found in nib 2. Nib 2 only partly works. Changes made in the custom view do not show up in the managed object model or in the user interface found in nib 1. When establishing a binding programmatically do you also need to setup key value observing? I thought a binding was bi-directional and included both key value coding and observing. Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 6:04 AM, Richard Somers rsomers.li...@infowest.com wrote: I have a managed object context with two attached NSObjectControllers in entity mode. Both controllers control the same entity. Important: do you really mean entity, or do you mean managed object? managed object model nib 1 controller user interface bind in interface builder nib 2 controller user interface (custom view) bind in code programmatically You need to describe precisely what you've done in both cases, which includes posting your code. You also make no mention of what managed object context your controllers are hooked up to. Nib 1 works. Entity changes produce by the user interface show up in the managed object model and in the custom view found in nib 2. Here, you mean to say that managed object property changes show up in your managed object context. Nib 2 only partly works. Changes made in the custom view do not show up in the managed object model or in the user interface found in nib 1. So now we also need to see your custom view code. When establishing a binding programmatically do you also need to setup key value observing? I thought a binding was bi-directional and included both key value coding and observing. No, bindings are not directional, and only do whatever you tell them to. NSObject's implementation of -bind:toObject:… starts observing the specified keypath, and its implementation of - observeValueForKeyPath:… attempts to use KVC to set a property with the same name as the binding. 99% of the time you're going to provide a custom implementation of both of these methods, and not calling super's implementation. Neither of these scenarios handles the reverse case. --Kyle Sluder___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 9:40 AM, Kyle Sluder wrote:
Nib 2 only partly works. Changes made in the custom view do not
show up in the managed object model or in the user interface found
in nib 1.
So now we also need to see your custom view code.
Here is the code for nib 2 which only partly works. Changes to the
model property num are reflected in the custom view but changes to the
num property in the custom view do not show up in the model.
All code in the custom view that touch the num property use the
accessor methods. The controller in the nib is in entity mode and
bound to File's Owner (MyDocument) managed object context.
@interface MyView : NSView
{
double num;
}
@end
@implementation MyView
- (double)num
{
return num;
}
- (void)setnum:(double)newNum
{
[self willChangeValueForKey:@num];
num = newNum;
[self didChangeValueForKey:@num];
}
@end
@interface MyDocument : NSPersistentDocument
{
IBOutlet MyView *myView;
IBOutlet NSObjectController *controller;
}
@end
@implementation MyDocument
- (void)windowControllerDidLoadNib:(NSWindowController
*)windowController
{
[super windowControllerDidLoadNib:windowController];
[myView bind:@num toObject:controller
withKeyPath:@selection.num options:nil];
}
@end
Thanks for looking at this.
Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Wed, Nov 4, 2009 at 12:17 PM, Richard Somers
rsomers.li...@infowest.com wrote:
All code in the custom view that touch the num property use the accessor
methods. The controller in the nib is in entity mode and bound to File's
Owner (MyDocument) managed object context.
Okay, but as I said before, the default NSObject bindings
implementation only set up KVO in one direction. If you call -[myView
bind:@num toObject:myController withKeyPath:@someModelKeyPath
options:0], KVO will only occur from [myController].someModelKeyPath
-- [myView].num. NSObject doesn't (and can't) also set up the
reverse direction.
@interface MyView : NSView
{
double num;
}
@end
@implementation MyView
- (double)num
{
return num;
}
- (void)setnum:(double)newNum
This is not a KVC-compliant accessor for the num property. It needs
to be named -setNum:.
{
[self willChangeValueForKey:@num];
Do not do this if you have not overridden
-automaticallyNotifiesObserversForKey: to return NO for the num key.
[myView bind:@num toObject:controller withKeyPath:@selection.num
options:nil];
This invokes the default implementation of
-bind:toObject:withKeyPath:options:, which takes care of the model -
view communication. You now need to take care of the view - model
communication. As described in the User Updates a Value in the User
Interface section of the Cocoa Bindings Programming Topics, you can
call -setValue:forKeyPath: on the toObject and withKeyPath arguments
of the original binding (you can get this information by calling
-infoForBinding). Or you might have some custom logic that informs
the controller/model of the change in a different way.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 3:17 PM, Richard Somers wrote:
@interface MyView : NSView
{
double num;
}
@end
@implementation MyView
- (double)num
{
return num;
}
- (void)setnum:(double)newNum
{
[self willChangeValueForKey:@num];
num = newNum;
[self didChangeValueForKey:@num];
}
@end
When the view changes num, it need to push the change to the bound
model objects.
See mmalc’s Graphics Bindings sample:
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
- Jim
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 2:31 PM, Kyle Sluder wrote: This invokes the default implementation of - bind:toObject:withKeyPath:options:, which takes care of the model - view communication. You now need to take care of the view - model communication. As described in the User Updates a Value in the User Interface section of the Cocoa Bindings Programming Topics, you can call -setValue:forKeyPath: on the toObject and withKeyPath arguments of the original binding (you can get this information by calling - infoForBinding). Or you might have some custom logic that informs the controller/model of the change in a different way. On Nov 4, 2009, at 2:34 PM, Jim Correia wrote: When the view changes num, it need to push the change to the bound model objects. See mmalc’s Graphics Bindings sample: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Sometimes Cocoa can be overwhelming. This will help. Thank you so much. :) Richard ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On 05/11/2009, at 8:42 AM, Richard Somers wrote: See mmalc’s Graphics Bindings sample: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Sometimes Cocoa can be overwhelming. This will help. Thank you so much. :) You might also find this blog post very helpful: http://www.tomdalling.com/cocoa/implementing-your-own-cocoa-bindings -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic Binding KVC KVO
On Nov 4, 2009, at 5:20 pm, Rob Keniger wrote: See mmalc’s Graphics Bindings sample: http://homepage.mac.com/mmalc/CocoaExamples/controllers.html Sometimes Cocoa can be overwhelming. This will help. Thank you so much. :) You might also find this blog post very helpful: http://www.tomdalling.com/cocoa/implementing-your-own-cocoa-bindings Rather more relevant, the documentation pretty-nuch explains the simpler of the two bound views in the Graphics Bindings example: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html#//apple_ref/doc/uid/20002373 Sample code just for the joystick view is also available: http://developer.apple.com/mac/library/samplecode/BindingsJoystick/ mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: Programmatic binding not working both ways?
on 4/8/08 9:16 PM, [EMAIL PROTECTED] purportedly said: I'm using bind:toObject:withKeyPath:options: to programmatically set up bindings from a set of proxy objects (the receiver) to various properties on a model object, and while changes to the model properties are properly being reflected in the proxies, changes to the proxy properties are not being propagated back to the model as I expect. IIRC, bindings are only one-way. The two-way behavior you have seen is a function of NSObjectController and its subclasses. Your proxy objects will have to somehow communicate their changes to the model manually or using KVO. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Programmatic binding not working both ways?
I'm using bind:toObject:withKeyPath:options: to programmatically set up bindings from a set of proxy objects (the receiver) to various properties on a model object, and while changes to the model properties are properly being reflected in the proxies, changes to the proxy properties are not being propagated back to the model as I expect. I know I only have at most a couple of paragraphs to set this up, so: I have a master-detail interface where the detail pane displays a list of only the non-empty properties of the selection in the master table. (Sort of like the Address Book, which only renders non-empty fields.) Edits in the detail view need to be pushed back to the model object properties. I'm using a two-column table for the detail view; the first column of each row renders the label for a property, the second column shows the property value. The table columns are bound to fieldName and fieldValue properties of the selection of a subclass of NSArrayController. The content of the NSArrayController is reset whenever the master selection is changed; the content is comprised of the proxy objects, where each proxy represents a single non-empty property of the selection. Each proxy object uses bind:toObject:withKeyPath:options: to bind its fieldValue property to the appropriate property of the selection. This works to properly render and update the values in the detail table, but editing the values in the detail table does not propagate changes back to the selection (from where, I assume, they should be propagated back to the model objects backing the master list. Is there something more I need to do to make this happen? TIA, Doug K; ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
