NSOutlineView, calling reloadData during setObjectValue causes crash?

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 doented about doing
this in an NSOutlineView? If there's something else I need to do instead,
what is it?

In <OTidndWhkvX6IPuiXTWc-gspeakeasy.net> Paul Forgey wrote:

Quote:

---

> 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 doented
> 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]matttidbits.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.

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

Quote:

---

> In <OTidndWhkvX6IPuiXTWc-gspeakeasy.net> Paul Forgey wrote:

Quote:

---

> > 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 doented
> > 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 doentation seems to suggest reloadData simply
sets a flag that is read the next time the view is displayed.

In article <207eddbd.0309171145.5397a6f7posting.google.com >,
[email]paulfaphrodite.com[/email] (Paul Forgey) wrote:

Quote:

---

Quote:

---

> > 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.

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

Quote:

---

> In article <207eddbd.0309171145.5397a6f7posting.google.com >,
> [email]paulfaphrodite.com[/email] (Paul Forgey) wrote:
>

Quote:

---

Quote:

---

> > > 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: