Re: View hierarchy problem

[Andreas Höschler]

Hi,

> 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 the view hierachy, but it 
> is nevertheless referenced and used by an event coming in after its 
> removal.

I have worked around this problem in my app now by doing the refresh 
0.1 after the mouse click.

- (void)windowDidBecomeKey:(NSNotification *)aNotification
{
   // we load the shelf with some delay to work around a bug in 
GNUstep. When the mouseDown: event reaches the window,
   // the location of the event is used to dermine the subview with 
hitTest. This search is somehow forwarded to
   // GSDecorationView which returns a view that is no longer in the 
view hierachy (has been removed)!! Aua!
   [self performSelector:@selector(loadShelf) withObject:nil 
afterDelay:0.1];
}

But there seems to be a minor issue in gui. This should work without 
the delay (actually does on MacOSX). But it's probably not worth to 
burn dev resources with minor stuff like this right now. Up to more 
important stuff! :-)

Best wishes,

  Andreas