Re: NSArrayController/TreeController out of bounds
Re: NSArrayController/TreeController out of bounds
- Subject: Re: NSArrayController/TreeController out of bounds
- From: "Jeffrey J. Early" <email@hidden>
- Date: Thu, 10 Nov 2005 12:04:32 -0800
- Thread-topic: NSArrayController/TreeController out of bounds
One workaround breaks something else...
Although not listed in the NSTreeController docs, there is mention of "add:"
not working once the "count key path" is set in the bindings documentation:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Conc
epts/CntrlContent.html
Look under "Traversing Tree Content with an NSTreeController"
NSTreeController ain't pretty. Given all the trouble that NSTreeController
causes and considering that the undocumented "-observedObject" might break
in future versions, I'm not sure it's worth the trouble to use
NSTreeController, rather than just code it all up by hand.
on 11/10/05 6:05 AM, Ian G. Gillespie at email@hidden wrote:
> I tried the workaround mentioned below, but when I had the children
> key path I can't even add items to the selection--bound list. It
> seems that 10.4.3 has introduced some nasty bugs in NSTreeController
> and/or CoreData. For those that want to see the test application,
> you can get it here www.iggsoft.com/Test2.zip
>
> To illustrate the bug where you can NOT add items to the selected
> object on the right, add "childrenCount" as the key path to the
> "Items" tree controller in IB. If this key path is not their (as the
> default when you download it) everything works as expected, accept of
> course for the bug mentioned in the original email.
>
>> FROM : Jeffrey J. Early
>> DATE : Tue Nov 08 23:14:48 2005
>>
>> I figured out a work around for this problem.
>>
>> I first confirmed that binding an NSArrayController's ContentArray
>> to the
>> arrangedObjects of another NSArrayController does work, whereas
>> doing the
>> same with an NSTreeController does not.
>>
>> Simply by adding the optional "Count key path" to the
>> NSTreeController fixed
>> the problem. Somehow despite the NSTreeController getting a KVO
>> notification
>> that the arrangedObjects changed and hence knowing to reload the
>> objects, it
>> fails to update its count of the array, whereas the optional count
>> binding
>> forces the change.
>>
>> Anyway, maybe this is expected behavior, but regardless, I now have
>> a work
>> around.
>>
>> Thanks,
>> Jeffrey
>>
>> on 11/6/05 1:26 PM, Jeffrey J. Early at <email_removed> wrote:
>>
>>> Howdy all --
>>>
>>> For various reasons, I'm trying to bind an NSTreeController's
>> "ContentArray"
>>> to the "arrangedObjects" of an NSArrayController. The primary
>> reason being
>>> that I want to sort the objects in the NSArrayController, have the
>>> NSTreeController list the root objects in that order, but let the
>> children
>>> objects be sorted in a separate sort pattern.
>>>
>>> The problem that I'm running into is that the NSTreeController
>> doesn't seem
>>> to get key-value notification that the NSArrayController's
>> "arrangedObjects"
>>> have changed, whether just sorted or swapped out all together.
>>>
>>> I've made a fairly reduced test case. Run the app, click
>> "Generate new
>>> function". One function is generated with four "subfunctions" and
>> another
>>> with one subfunction. If you view the first function, and then
>> the second,
>>> you'll find that NSTreeController goes out of bounds on its array
>> and throws
>>> an error.
>>>
>>> To see how everything works without the tree controller, simply
>> unbind the
>>> NSTreeController's "ContentArray" and run it again.
>>>
>>> http://oregonstate.edu/~earlyj/NSArrayControllerDebug.zip
>>>
>>> Anybody see what's wrong and causing this to happen?
>>>
>>> Thanks for any help,
>>> Jeffrey
>>>
>>> PS - This test case is actually modified from one where I was
>> assessing
>>> CoreData performance issues. I'll post my findings and real test
>> case for
>>> that shortly here....
> _______________________________________________
> 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
_______________________________________________
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