mouseEnter-Leave conundrum

[J. Landman Gay]

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.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com