What the heck is wrong with AS 3.0?

Question

I'm having a whale of a time with rollovers in AS 3.0. In
this app:
RexMap
The bottom buttons are simple movieclips with an up and over
state.
When you rollover and out of them they are very buggy. They
have listeners and that is is. myButton.gotoAndPlay("over");
The button to the left of the one with the green arrow. This
is for the visible elements on the application. When the pop-up
comes up, "MOUSE_OVER" doesn't work at all!!!! Why?
"ROLL_OVER" is extremely buggy. Try it, works maybe half the
time.
I've been programming in AS for 5 years and 2.0 was perfect
with the rollovers of movieclips. Should I be doing something
different, or is this AS 3.0, for now?
Thanks,
C

Answer 1

C-Rock,
> I tried using the mouseEnabled and the mouseChildren
> to improve performance of the highest buttons when the
> pop-up is up. The "ok" and "cancel" buttons still work
> like crap.
I may not have understood what you were after at first. In
my initial
reply, I was thinking you wanted the icon buttons along the
bottom to
continue to respond when the blue swatch was obscuring them.
At this point, I can see what you mean about the OK and
Cancel buttons:
it's easy to fool them by rapidly shaking the mouse. From
what I'm seeing,
I have the following thoughts: your events may be firing more
than once,
because the interior elements of your buttons (the lettering,
the curve
shape) may be active child objects of the buttons themselves
-- for example,
if your text fields are dynamic or of the shapes are movie
clips. So you
may want to set those buttons' mouseChildren properties to
false ...
elementsPopup.boxMC.okBTN.mouseChildren = false;
elementsPopup.boxMC.okBTN.addEventListener(MouseEvent.ROLL_OVER,
elementsOkOver);
I realize you just said you did that -- and I believe you --
but since
your earlier code samples don't show as much, I wanted to
cover all the
bases. I'm also noticing that the hit area of these buttons
seems to extend
past the edge of the button artwork itself (just for the
OK/Cancel). That
might be another mouse child culprit.
The overall framerate of your movie may be an issue here,
too.
Since these buttons don't seem to tween, by not bypass movie
clips for
the time being and use button symbols? That may rescue you a
few headaches
for the moment and buy you time to experiment with movie clip
event handlers
later.
Your code looks fine, so I'm interested to know if the same
code
succeeds for you in cases where the artwork is flat-out dull.
Start a new
FLA and whip up a quick movie clip-based button whose artwork
is simply
comprised of identical squares (graphics or simply shapes).
Use the
MOUSE_OVER event. Should work as expected. Now introduce text
(dynamic and
static) to see how the event handling changes unless you
specify
mouseChildren = false (use trace() to test). If mouseChildren
is true
(default), you'll see your trace() get triggered every time
you mouse away
from the dynamic text "back on" to the simple square
background. This isn't
the case for ROLL_OVER, regardless of the mouseChildren
setting.
So you can see that granularity and subtlety have increased,
at least in
this scenario. Conceptually, event handling is still the
same, but some of
the finer details have changed a bit.
Chin up! :)
David Stiller
Contributor, How to Cheat in Flash CS3
http://tinyurl.com/2cp6na
"Luck is the residue of good design."