On May 14, 2007, at 1:36 PM, J. Landman Gay wrote:
Devin Asay wrote:
I've run into an interesting problem in a small demo stack I'm
working on. I am creating an interactive labeled picture in which
a label field appears when the user mouses over an object in a
photograph. I use a filled, partially transparent irregular
polygon graphic to define the outline of the object in the photo I
want to label. The label field overlaps the graphic object (this
detail is important.) I use a script like this on the card to
control the hiding and showing of the label field:
on mouseEnter
if the name of the target contains "graphic" then show fld
"myLabel"
end mouseEnter
on mouseLeave
if the name of the target contains "graphic" then hide fld
"myLabel"
end mouseLeave
Pretty straightforward. Now consider this sequence of events:
mouse enters graphic --> field is shown
mouse leaves graphic --> field is hidden
No problems. But this is what happens when the mouse enters the
graphic, then, without leaving the graphic, enters the now visible
field:
mouse enters graphic --> field is shown
mouse enters field --> since mouse is over field, it has left the
graphic, so
mouse has left graphic --> field is hidden
mouse has entered graphic again --> field is shown
mouse has left graphic --> field is hidden
mouse has entered graphic again --> field is shown
... [ad infinitum]
This resultant "fluttering" of the field only stops after the
mouse has been moved out of the graphic and enough time has
elapsed so that all of the queued mouseLeave/mouseEnter events
have run through.
go stack url "http://asay.byu.edu/enter-leave.rev"; --to see a
demonstration
I understand why this happens, and it seems consistent with the
engine logic, so I'm not inclined to call it a bug. On the other
hand, when uncontrolled "thrashing" of messages like this happens,
it feels like a bug.
What do you all think? Should I report it as a bug? Is there an
obvious workaround that I'm missing? (FlushEvents has no effect on
these messages.) Insights appreciated.
Try:
on mouseLeave
if the name of the target contains "graphic" then
lock messages
hide fld "myLabel"
end if
end mouseLeave
I'm not sure it's a bug though I agree it probably feels like one.
Thanks, Jacque. That gets me part way there. The "thrashing" stops,
but I still get the undesired hiding of the label field when I move
the mouse over the part of the field that is also inside the graphic.
It also prevents a label from showing in an adjacent graphic, if I
move directly from one graphic to another, because the messages are
locked. Ergo, no mouseEnter message for the adjacent object....
Devin
Devin Asay
Humanities Technology and Research Support Center
Brigham Young University
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
