Re: setContent: vs bind:toObject:withKeyPath:options: ?
Re: setContent: vs bind:toObject:withKeyPath:options: ?
- Subject: Re: setContent: vs bind:toObject:withKeyPath:options: ?
- From: Keith Blount <email@hidden>
- Date: Thu, 29 Dec 2005 03:08:17 -0800 (PST)
Thanks again for your reply.
>
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?
Exactly. The thing is, though, if you set the content
array through IB or use the bind: method, it works as
expected (well, almost - see below...). Very strange,
as you would expect NSArrayController and
NSTreeController to work in similar ways.
>
Depending on your application's target audience and
>
release date, it
>
might be too early to drop Panther support.
My app is only in beta and won't be released until
Q1/Q2 2006, so I decided to take advantage of certain
Tiger-only features (not just NSTreeController) and
drop Panther support during development.
>
NSTreeController was introduced in Tiger, so it's
>
quite possible that
>
it has more than a few bugs. Maybe you should avoid
>
it entirely?
Yes, I have in fact decided to drop NSTreeController
altogether, as you suggest. Early on in development I
spent a lot of time trying to get NSTreeController
working for the main source lists in my app and
abandoned it then. I decided to give it another whirl
for a much simpler outline view, as I thought it might
be more suited for something more basic. But quite
apart from the -setContent: issue, I then found that
drag-and-drop started issuing errors when the content
array was bound (it worked fine when no array was
bound to it), and the errors were coming from private
(undocumented) methods that I was forced to use in
order to support D'n'D (it has been well-documented
elsewhere that the only way to support D'n'D in
NSTreeController is via private methods). I was
uncomfortable using private methods anyway, so I have
finally abandoned it altogether. Hopefully
NSTreeController will become more useful in the
future. I have already filed several bugs about
NSTreeController, and as you suggest I will file
another one about this.
Many thanks again,
Keith
--- Camillo Lugaresi <email@hidden> wrote:
>
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
>
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
_______________________________________________
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