On May 27, 2005, at 5:49 AM, Zdzislaw Losvik wrote:
This is at best misleading. The code specifies binding, not observing. The basic goal of binding is to keep two values synchronised. If you use the bind:... method to bind a text field's 'value' to a keypath in an object controller, you could get the expected behaviour.
I have read a dozen of articles about bindings. Some of them were great. When I was done I was convinced that bindings always work two-ways. The basic article by Apple about a joystick ( HowDoBindingsWork ) has lots of sample impementation code. Although I have read it several times, until yesterday, I was sure that this glue code is already implemented in NSObject. But NO, user has to write it for his class by himself. Basic NSView subclasses have these methods implemented, but when you use your custom view this has to be added.
that is correct. If you want a bindings enabled view, you need to implement code yourself.
I have tried rewriting my code to bind brick1 to NSObjectController(brick2) - it makes no difference. brick1 observes brick2, but reverse is not true.
No, because you're still connecting a model object to a model object.
And it makes no difference. Also please note that according to Apples documentation binding two objects together is perfectly legal, just some minor features (NSEditor and NSEditorRegistration protocols, placeholder and multiselection values) are lost.
can you point this out specifically? I'll clarify this so that there is no way that it can be misunderstood.
Also I do not access private variables this way: brick1->intValue. I did it here on purpose as I wanted to make sure that no binding magic happens behind the scene when I access these values and that I get the value that really is there.
It seems to me that bindings are not fully implemented in Mac OS X. It is just a bit odd that so much advertised technology does not work as it is supposed to. Values are not kept in sync. Probably there was a reason of doing so.