[squeak-dev] Bug in #tryInvokeHalo:
marcel.taeumel at hpi.de
Fri Apr 26 10:59:13 UTC 2019
that's the correct fix. :-)
Am 25.04.2019 20:59:15 schrieb Chris Muller <asqueaker at gmail.com>:
> > I just tried those steps. I can reproduce the problem when I click in
> > the *gray area* (e.g., parent-most morph) on the right side of the
> > halos, but when its in that same gray area on the left hand side, or
> > any other morph like the Help button, it works. Very strange. There
> > must be something unique about this particular "Same" game's Morph
> > structure or w.r.t. how it interacts with the new implementation of
> > #tryInvokeHalo:. This is the first Morph I've seen behave this way.
> No, the bug is very general - I just gave fast and easy steps to
> reproduce it. But you can just compose three morphs (Morph instances), a
> big one with two smaller ones as children, and you get the same problem
> in areas where the top morph overlaps a system window.
Strange, I just wrote the following code to try it:
| a b c| a := Morph new extent: 200 at 200.
b := Morph new color: Color green; position: 50 at 50.
c := Morph new color: Color yellow; position: 100 at 100.
a addMorphBack: b; addMorphBack: c; openInHand
and it worked. But then, I did it again, and it didn't.
> As I said, the problem is "simply" that #tryInvokeHalo: builds a stack
> of potential targets at the clicked point, then for some reason that I
> did not investigate discards the first one with the explicit comment
> "existingHalo is first on the stack, not a target", while it *is* the
> target here.
Ah! That's the clue we needed. I'm not exactly sure why the halo
morph wouldn't be the top one on the stack either, but this patch uses
a much more-resilient way to do that. Let me know if this works,
we'll commit it to trunk.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev