Hello Clark,
Many thanks for the reply, much appreciated. I figured the "re-entry" probably
meant something along those lines, but I wasn't sure, so thank you for
clarifying it. I'm not calling anything explicitly in my
-outlineView:heightOfRowByItem: method, and there are no other threads
operating
on it, but that said, the row resizing code is rather complicated as it live
resizes the rows during editing (by checking row heights, ending editing,
reloading data and then carrying on editing - it's not pretty) and based on
various column content, so there's a lot going on. At least your explanation
gives me something to look for in the absence of a reproducible case.
Thanks again and all the best,
Keith
----- Original Message ----
From: Clark Cox <clarkc...@gmail.com>
To: Keith Blount <keithblo...@yahoo.com>
Cc: cocoa-dev@lists.apple.com
Sent: Wed, September 8, 2010 7:42:55 PM
Subject: Re: NSTableView/NSOutlineView variable row height code has detected
re-entry.
On Wed, Sep 8, 2010 at 11:11 AM, Keith Blount <keithblo...@yahoo.com> wrote:
> Hello,
>
> I have an NSOutlineView with variable row heights, as determined in
> my -outlineView:heightOfRowByItem: delegate method. This has always seemed to
> work fine, and the code of this delegate method hasn't changed much in the
past
> three years, but I have had a user report a case whereby his outline view
> appeared completely blank and this message appeared on the console:
>
> NSTableView/NSOutlineView variable row height code has detected re-entry.
> Avoiding a crash....
>
> After restarting the program, he hasn't seen the problem since, so I haven't
> been able to reproduce it. But I did see it myself during testing once last
>year
> and then, too, I wasn't able to reproduce it a second time. I've Googled for
> this message and can only find a couple of other posts referencing it, with no
> solution. One problem is that I don't know exactly what the message means by
> "re-entry", so I'm not sure whether the problem is with the variable row
height
> code itself (which seems fine), or because the row height code is somehow
> getting called twice during layout, or something else entirely. I've gone
> through the code but can find no obvious culprit (which is probably not
> surprising given the rarity of the error).
>
> Has anybody else seen this error, or does anybody know what it means?
Essentially, it means just what it says. Something has called into the
code responsible for recording the row heights for a table view, while
that same code was already running.
Some potential causes:
- Recursion: Your -tableView:heightOfRow: delegate method is doing
something that is calling -reloadData, or
-noteHeightOfRowsWithIndexesChanged: (or something else that causes
recalculation of row heights)
- Concurrency: You're accessing the table, its delegate, or its data
source from multiple threads.
--
Clark S. Cox III
clarkc...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
