On Jan 28, 2010, at 4:04 PM, Quincey Morris wrote:
But you did nothing like what's in that example. It defines (and
exposes) 2 named bindings of the custom view object, and implements
all of the behavior associated with each binding. The [bind:...]
implementation is just one piece of the whole.
Thanks for the reply.
As I understand it, exposing the binding relates to exposing the
binding to Interface Builder. Since I am not using Interface Builder
exposing the binding is a non-issue.
As it happens (whether by accident or design isn't clear), you can
pass a property name as the first parameter instead of a true
binding name, and you'll end up with a uni-directional "binding" ...
Using the default NSObject implementation of -
bind:toObject:withKeyPath:options: is only one-way. This behavior is
not dependent on some characteristic of the first parameter. The
binding will push model changes back to the controller or view; but
view and controller changes must be manually propagated to the model.
Currently for this particular binding that is all I need is a one-way
binding.
Regarding the "true binding name" that is something that has been
confusing. At first I thought there was something magic in the
"binding name". The documentation states that the first parameter for -
bind:toObject:withKeyPath:options: is "The key path for a property of
the receiver previously exposed using the exposeBinding: method." If
we are not using Interface Builder then it simply becomes "The key
path for a property of the receiver". My instance variable "array" is
a property of "CustomObject" and so I think this is why this works as
advertised.
This may be sufficiently functional for your current project, but
it's not really a binding, ...
True this is not a fully functional "binding" as found in Interface
Builder but for this programmatic binding I do not need all the bells
and whistles.
... and it's not at all obvious that this behavior will continue to
exist.
You do have a point here. Apples documentation is really geared
towards a "binding" being what you see in Interface Builder which
behind the scenes appears to be a multitude of moving pieces and
parts. Programmatic bindings on the other hand are somewhat of a black
art perhaps because of the lack of documentation or the complexity of
a fully functional binding as implemented by Apple in Interface Builder.
That blog clearly states that [bind:...] is only half of the
behavior of a binding.
That is true. I think the question might be does -unbind: only undo
what was done by using -bind:toObject:withKeyPath:options: or does it
do more than that? I understood that they were just complementary
methods. Use one and then use the other to nullify the effect of the
first. The documentation seems to indicate that this is the case.
Indeed for my other programatic bindings it appears to work like this
except for this particular one which has a memory leak.
What's wrong with:
for (id foo in arrayController.arrangedObjects)
...
? After all, "arrangedObjects" is documented to be an array. (It's
actually a kind of proxy, but it has the behavior of an array.)
Interesting. I tried this as you suggested but it results in compiler
errors.
error: request for member 'arrangedObjects' in something not a
structure or union
error: expression does not have a valid object type
In general, you can't observe an array (though you can observe an
array property of an arbitrary object), and KVC conventions make
"arrangedObjects.changed" be a reference to an array. Presumably it
works because there is something special about the "arrangedObjects"
proxy, but there's not guarantee of this behavior AFAIK.
My NSArrayController is wired to a managed object context. I am
observing the property of a managed object by passing the observation
through the array. This part of my program has never not worked and I
have never had any problems with it.
Not that it means anything but here is an example of someone doing the
same thing.
http://stackoverflow.com/questions/973208/how-to-get-notified-of-changes-to-models-via-an-nsarraycontroller
--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
