Re: BUG [ 100250 ] highlight menu item sometimes fails

[Richard Frith-Macdonald]

On Sunday, February 3, 2002, at 12:29 AM, Fred Kiefer wrote:

> I had a deeper look into the problem behind the bug 100250 and found
> that it is created by a view that is moved to another window, while the
> view needs display. In that specific constellation the method [NSView
> setNeedsDisplayInRect:] does not work correct. As the whole area of the
> view is already invalid the new window (and the super views) is not
> marked as needing display.
> There are multiple ways to resolve this problem and I am not sure which
> is the best. Currently I would prefer to flag the view when moving it to
> a new superview first as not to need display and than as needing
> display. That way the invalid area is first cleared and than everything
> works as expected. This would require changes to the methods
> [addSubview:], [replaceSubview:with:] and
> [addSubview:positioned:relativeTo:].
> Another way to do it would be to flag a view as not needing display in
> the [removeFromSuperview:] and
> [removeFromSuperviewWithoutNeedingDisplay:] methods. Or to try to handle
> this case in [setNeedsDisplayInRect:], but this would need a lot of
> extra checks.

When a view is added to another view, it gets marked as needing display
anyway.  The problem is that if it is already marked as needing display,
the propagation of that information up the view hierarchy is optimised
away.
So what's needed is to unmark it when removing it so that the marking
as needing display upon addition can operate correctly.  This can be done
with one call to -setNeedDisplay: in the -removeSubview: method, since 
all
removal of views uses that method.

> There is another smaller problem here in the method [NSWindow
> orderWindow:relativeTo:]. Here the sending of needs display calls from
> the runloops to the window is only started when the window does not need
> display. This seem to be the wrong way round.

Yes ... a bug.

I added your fixes.