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
|