NSOutlineView, calling reloadData during setObjectValue causes crash?

[Paul Forgey]

I've got two very similar things going on in both an NSOutlineView and an
NSTableView. If the user edits the text in the leftmost column, this
changes the key in a dictionary, which can cause the data to be reordered.
If this happens in outlineView:setObjectValue:forTableColumn:byItem, I send
a reloadData: to the NSOutlineView instance after the data used by the data
source has been changed.

In an NSTableView, this works fine. In an NSOutlineView, this causes a
crash sometime after setObjectValue: has returned. I've checked and
re-checked my data source. Especially since an NSTableView works just fine,
is there a known problem or limitation that isn't documented about doing
this in an NSOutlineView? If there's something else I need to do instead,
what is it?

[matt neuburg]

In <OTidndWhkvX6IPuiXTWc-g@speakeasy.net> Paul Forgey wrote:

> I've got two very similar things going on in both an NSOutlineView and
> an NSTableView. If the user edits the text in the leftmost column,
> this changes the key in a dictionary, which can cause the data to be
> reordered. If this happens in outlineView:setObjectValue:
> forTableColumn:byItem, I send a reloadData: to the NSOutlineView
> instance after the data used by the data source has been changed.
>
> In an NSTableView, this works fine. In an NSOutlineView, this causes
> a crash sometime after setObjectValue: has returned. I've checked and
> re-checked my data source. Especially since an NSTableView works just
> fine, is there a known problem or limitation that isn't documented
> about doing this in an NSOutlineView? If there's something else I
> need to do instead, what is it?

If you believe the problem is that you're calling reloadData *during*
setObjectValue, then you can test that hypothesis by calling reloadData *
after* setObjectValue has returned. You can arrange that easily through
delayed execution. m.

--
matt neuburg, phd = [email]matt@tidbits.com[/email], [url]http://www.tidbits.com/matt[/url]
REALbasic: The Definitive Guide! 2nd edition!
[url]http://www.amazon.com/exec/obidos/ASIN/0596001770/somethingsbymatt[/url]
Subscribe to TidBITS. It's free and smart.

[Paul Forgey]

matt neuburg <matt@tidbits.com> wrote in message news:<20030916095229915-0700@news.la.sbcglobal.net>...

> In <OTidndWhkvX6IPuiXTWc-g@speakeasy.net> Paul Forgey wrote:

> > I've got two very similar things going on in both an NSOutlineView and
> > an NSTableView. If the user edits the text in the leftmost column,
> > this changes the key in a dictionary, which can cause the data to be
> > reordered. If this happens in outlineView:setObjectValue:
> > forTableColumn:byItem, I send a reloadData: to the NSOutlineView
> > instance after the data used by the data source has been changed.
> >
> > In an NSTableView, this works fine. In an NSOutlineView, this causes
> > a crash sometime after setObjectValue: has returned. I've checked and
> > re-checked my data source. Especially since an NSTableView works just
> > fine, is there a known problem or limitation that isn't documented
> > about doing this in an NSOutlineView? If there's something else I
> > need to do instead, what is it?

>
> If you believe the problem is that you're calling reloadData *during*
> setObjectValue, then you can test that hypothesis by calling reloadData *
> after* setObjectValue has returned. You can arrange that easily through
> delayed execution. m.

I'm not quite certain how I would go about doing that. I did,
however, add a temporary method to send a reloadData to the
NSOutlineView in response to a temporary menu item. The NSOutlineView
reloads just fine when I do this (that doesn't solve my problem of
course).

I'm not certain calling reloadData during setObjectValue is really the
problem, since the documentation seems to suggest reloadData simply
sets a flag that is read the next time the view is displayed.

[Michael Ash]

In article <207eddbd.0309171145.5397a6f7@posting.google.com >,
[email]paulf@aphrodite.com[/email] (Paul Forgey) wrote:

> > You can arrange that easily through
> > delayed execution. m.

>
> I'm not quite certain how I would go about doing that.

It is (as usual with Cocoa) unbelievably easy.

Instead of:

[thingy reloadData]

you do:

[thingy performSelector:@selector(reloadData) withObject:nil withDelay:0]

This will send reloadData once you get done doing what you're doing and
your program returns to the run loop.

[Paul Forgey]

Michael Ash <mail@mikeash.com> wrote in message news:<mail-5C9C01.22033817092003@localhost>...

> In article <207eddbd.0309171145.5397a6f7@posting.google.com >,
> [email]paulf@aphrodite.com[/email] (Paul Forgey) wrote:
>

> > > You can arrange that easily through
> > > delayed execution. m.

> >
> > I'm not quite certain how I would go about doing that.

>
> It is (as usual with Cocoa) unbelievably easy.
>
> Instead of:
>
> [thingy reloadData]
>
> you do:
>
> [thingy performSelector:@selector(reloadData) withObject:nil withDelay:0]
>
> This will send reloadData once you get done doing what you're doing and
> your program returns to the run loop.

That solved it. Thanks! This means reloadData: does do more than
setting a state flag, and the NSOutlineView in fact can't handle
reloadData: during setObjectData: