Re: View hierarchy problem

[Fred Kiefer]

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