AW: BUG? #changed sent to dragged morph does not work

Andreas Raab Andreas.Raab at gmx.de
Fri Feb 1 01:18:09 UTC 2002


David,

Nice catch! Turns out there was a little confusion about coordinate
frames in HandMorph. If you replace the last few lines in
HandMorph>>updateCacheCanvas: by the following, it'll work:

	"incrementally update the cache canvas"
	cacheCanvas translateBy: subBnds origin negated during:[:cc|
		rectList do: [:r |
			cc clipBy: r during:[:c|
				c fillColor: Color transparent. 
				self drawSubmorphsOn: c]]].


The coordinate frames of rectList (world relative) and cacheCanvas
(cache relative) were out of sync, so the code in HandMorph used to clip
against stuff _way_ outside the cache region. The above makes
cacheCanvas world relative before clipping, so that'll do the trick.

Cheers,
  - Andreas

> -----Ursprüngliche Nachricht-----
> Von: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] Im 
> Auftrag von David N. Smith (IBM)
> Gesendet: Freitag, 1. Februar 2002 01:47
> An: squeak-dev at lists.squeakfoundation.org
> Betreff: BUG? #changed sent to dragged morph does not work
> 
> 
> All:
> 
> I need to change a morph (actually one of its submorphs) 
> while the morph is being dragged. Merely making the change 
> (setting a color, say), then sending #changed, does nothing.
> 
> Making a change in, say, a mouse enter while dragging 
> interrupt handler does cause it to take effect.
> 
> I started reading code and it looks like #changed SHOULD 
> work, but it doesn't. Note that the hand tries to cache an 
> image of the dragged morph to make it drag faster. I've not 
> dug into the code far enough to fully grok all that is 
> happening and I'm hoping that someone who knows the code can help.
> 
> 
> I wrote a small test case and found some interesting things. 
> It's attached. It contains only one class, a submorph of 
> RectangleMorph, just 7 methods, and no changes elsewhere. See 
> the class comment for instructions on how to run it. You 
> initially get a single white rectangle at 10 at 10.
> 
> Pick it up and drag it to 0 at 0, keeping the button down. Note 
> that at one second intervals the color and border width 
> change randomly, as they should.  Now move it slowly away and 
> watch how the color change and border width only apply to 
> part of the rectangle. Note that it is the LRC. Huh?
> 
> Move it further away and drop it on the world. It turns 
> white, as it should. Pick it up and drag it around anywhere 
> but that funny TLC and it stays white. The #step method does 
> send #changed to self.
> 
> The drawing of the colors at the TLC looks like a bug; maybe 
> the morph origin is added twice to cause it to move away from 
> the TLC? The failure of #changed to work looks like one to me 
> too. Maybe it is the same bug?
> 
> 
> Now modify #step by removing the comments from around the 
> send of #alpha: so it looks like this:
> 
> 	self color: (Color random alpha: 0.999);
> 
> Now drag and see it all work. This is a necessary feature 
> since one cannot cache for fast dragging if it is 
> translucent. But it is an ugly work around to my problem.
> 
> 
> Put #step back as it was, with #alpha: commented out. Now go 
> to #wantsToBeCachedByHand and change it to return false. 
> Again, when dragged, the morph shows its changes, as it should.
> 
> 
> However, these work arounds cause the hand to redraw the 
> whole morph (and submorphs) at every step, a not so nice 
> feature when the morph is more complex and it has visible submorphs.
> 
> 
> Anyone got any ideas?
> 
> Thanks!
> 
> Dave
> 





More information about the Squeak-dev mailing list