[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: View hierarchy problem
From: |
Fred Kiefer |
Subject: |
Re: View hierarchy problem |
Date: |
Fri, 17 Aug 2007 23:14:43 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20060911) |
Andreas Höschler wrote:
> Hello all,
>
> I have an application with a shelf view that has a bunch of subviews
> (icons representing applications). In windowDidBecomeKey: I reload the
> shelf, meaning that I do removeFromSuperviewWithoutNeedingDisplay for
> all these subviews and then rebuild the shelf (recreate all the
> subviews). Doubleclicking on one of these subviews launches or activates
> the represented application.
>
> From time to time I get a core dump when doubleclicking from one app to
> the next on the shelf. By backtracing I found out that
>
> [NSWindow makeFirstResponder:];
>
> is called with a previoulsy removed (and released) view (one of the
> views that have been recreated earlier in windowDidBecomeKey:). Here is
> a pseudo backtrace of this
>
> [NSWindow makeFistResponder:] <--------
> [NSWindow sendEvent:];
> [NSApplication sendEvent:]
> [NSApplication run]
>
> I realized some code in [NSView removeSubview:] that is obviously meant
> to remove the to be removed view from teh view hierachy, but it seems it
> is still retained by some event circling around in the event loop and
> then causes the malfunction.
>
> Any idea how this error can be prevented or further tracked down?
>
No, really no idea how this could happen. The view used in sendEvent for
makeFristResponder comes from a hit test on the window view (_wv). This
means your removed and released view must still be in the window hierarchy.
Ah, now I see the issue: this view gets cached in sendEvent: before
makeKeyAndOrderFront: gets called. We just need to move the detection of
this view a few lines down. Could you please test this, before I make
this change?
Fred