That usually means drawRect: is being called while the table is already inside
its own drawRect: method.
I've had to deal with this recently. One possible way to find out where it's
happening is to subclass your table view and override drawRect:, then setup a
counter to check to see if the re-entry is occurring, something like this
(untested):
static int c = 0;
- (void)drawRect:(NSRect)rect
{
if (c > 0) {
// re-entry, set a breakpoint here
}
c++;
[super drawRect:rect];
c--;
}
The problem in my code was we were manually running the run loop which
continued to process events, causing the drawRect: to be called multiple times
(often in recursion, leading to a crash), so check to see if you're doing
anything like this. We've noticed on 10.6 it's much less prone to crash in
these situations, but 10.5/10.4 aren't as forgivable.
Kevin
On Sep 8, 2010, at 11:11 AM, Keith Blount 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?
>
> Many thanks in advance and all the best,
> Keith
>
>
>
> _______________________________________________
>
> 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/kainjow%40kainjow.com
>
> This email sent to kain...@kainjow.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
