Kent Humphrey wrote:
On 26 Jan 2006, at 11:01, Roman Blöth wrote:
Yes, that unfortunately is the only way to go - Director btw does
this much better: With Lingo you can pass every event, so it reaches
all objects that want to receive them...
I'm a Lingo refugee, feel my pain...
But one more comment on the method above:
Assume you have a onMouseEnter/onMouseLeave method on a background mc
within your container mc, and then place button mcs above this
background mc which want to receive on release events, then when the
mouse pointer hovers over such a button mc, the background mc will
receive a onMouseLeave-event, even though in fact the pointer still
is "within" the background area...
Which is what I just discovered with my test. So what is the solution?
Surely thing kind of thing is overcome every time someone codes a
simple dropdown kinda
thing?_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
There is no quick solution. If clip A contains clip B and both have
mouse events, clip A takes precedence. Period. Use xmouse/ymouse vs the
clip width and height. That's the extent of it. Or use a different
nesting order, using levels instead of depth for instance. But a clip
with mouse events containing a button will take precedence until those
events are removed.
- Andreas
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
