Re: setContent: vs bind:toObject:withKeyPath:options: ?
Re: setContent: vs bind:toObject:withKeyPath:options: ?
- Subject: Re: setContent: vs bind:toObject:withKeyPath:options: ?
- From: Camillo Lugaresi <email@hidden>
- Date: Thu, 29 Dec 2005 03:02:52 +0100
On 28/dic/05, at 20:27, Keith Blount wrote:
Many thanks for your reply, much appreciated.
Don't mention it!
I'm only surprised because it seems to work
differently in NSArrayController and NSTreeController
(and I had thought that -setContent: should in fact
set the "contentArray" binding). This whole issue
arose because I wanted to avoid the retain loop caused
by binding to file's owner described here:
http://theobroma.treehouseideas.com/document.page/18
(And in many other places too.)
Ah, I have seen that mentioned as well. So far I have not incurred
that infamous bug, even though I load and unload a nib where many
objects have bindings to the file's owner. However, I am not using
NSWindowController, and from the reports it *seems* that the bug only
appears when using that class (or a subclass).
As the workaround states there, calling -setContent:
on an NSArrayController after the nib has loaded
resolves this issue, and everything works as expected.
For instance, if I call [arrayController
setContent:myArray], I can then archive myArray in my
document and reload it on reopen. That is to say,
myArray is populated by the NSArrayController after
calling -setContent:. If I -add: to my arrayController
and then peek inside myArray using an NSLog(), I can
see that myArray has been populated as expected.
That's because the NSArrayController takes the array and uses it as
its actual live model. It doesn't make a copy, it just retains it. If
you retain it too, you can peek into it and see the changes (but you
can't be notified about them, since an NSArray does not have
observable properties as far as I can tell: that's one key difference
from using a binding).
However, this does *not* seem to work the same with
NSTreeController. If I do exactly the same thing with
an NSTreeController, calling [treeController
setContent:myTreeArray] after the nib has loaded, then
the treeController does *not* populate myTreeArray. In
fact, it seems to do nothing at all. If I -add: some
objects to my tree controller and then peek inside
myTreeArray, there is nothing there. Only
-bind:toObject:withKeyPath:options: works in this
case.
Even if you add objects at the root level? And you can see the new
object in a view bound to the controller, but it's not in your array?
Then I guess NSTreeController makes a separate copy of the array, or
turns it into something else entirely. I'm not sure if that's a bug
or just a different implementation choice; the documentation says
precious little about what to expect from setContent:.
There must be something I'm missing. I have it
working, but I am curious as to the reason for the
difference. NSTreeController seems very "buggy" to me
anyway (or at least, overly opaque), so maybe this is
just another quirk.
NSTreeController was introduced in Tiger, so it's quite possible that
it has more than a few bugs. Maybe you should avoid it entirely?
Depending on your application's target audience and release date, it
might be too early to drop Panther support. Although new features
will never get properly tested if nobody uses them... speaking of
which, you should probably file a bug about the behavior of
setContent in NSTreeController; if nothing else, someone at Apple
will look into it.
Camillo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden