Bob,

Bob Arning wrote:
> 
> On Sat, 22 Apr 2000 21:46:15 +0200 Stephan Rudlof <sr at evolgo.de> wrote:
> >I've found a curious update bug while implementing d&d for standard
> >browsers.
> >
> >Recipe to generate the bug in a few minutes:
> >
> >- go into a morphic project,
> >- open a Browser,
> >- select a system category,
> >- click twice to get the string morph,
> >- open an Inspector by its menu (red halo)
> >- evaluate
> >       self color: Color black
> >in it,
> >- select another category (one click for activating the window, second
> >click for selecting).
> >
> >Then updating the list morph doesn't work correctly.
> >
> >Try to
> >- reselect StringMorph with Inspector win,
> >- evaluate
> >       self color: Color gray
> >in Inspector,
> >- select another category.
> >
> >Now updating works as expected. It seems to arise only for Color black.
> >
> >
> >Any ideas?
> 
> Stephan,
> 
> That's because the PluggableListMorph unhighlights the previous selection by:
> 
> unhighlightSelection
>         selectedMorph ifNotNil: [selectedMorph color: Color black]
> 
> Since the morph was red when selected, this change invalidates the rectangle and causes it to be redrawn (both the text color by the StringMorph and the selection highlighting by the list itself). But, if you set the selected morph to black *while* it is still selected, then the unhilight code will not actually change anything and thus not mark that area as needing redraw.

Thank you Bob! In

Morph>>color: aColor
	color = aColor ifFalse: [
		color _ aColor.
		self changed].

starts the update by "self changed". I think I was too tired to find
this place (it was in my mind, that it could have to do with
optimization issues and I also saw the #unhighlightSelection method,
but...

Sorry!

> The method above could, I suppose, ensure that the bounds of the StringMorph are marked as changed just to be safe.

I think this would be better as the current implementation. Now we have
a dependency of the choice of the colors used in high/unhigh-lighting
(there is the same problem in the opposite direction).
E.g. if we'd use red as a color for a successful drop operation (or
black for an unsuccessful one, that was my original case), selecting
(deselecting) this item (if previously in the opposite status) wouldn't
work correctly.


Thanks,

Stephan

> 
> Cheers,
> Bob

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3