Link to home
Start Free TrialLog in
Avatar of iDeej
iDeejFlag for Australia

asked on

Converting this code from AS2 to AS3

How would I go about converting this code from AS2 to AS3:

this.testRandom=function(){
      if(Math.random()>.96){
            this.onEnterFrame=null;
            this.play();
      }
}
this.onEnterFrame=this.testRandom;
this.stop();

Here is the Compiler Error I'm getting:
Warning: 1090: Migration issue: The onEnterFrame is not triggered automatically by Flash Player at run time in ActionScript 3.0.  You must first register this handler for the event using addEventListener ( 'enterFrame', callback_handler).

Here is the output error:
WARNING: Actions on button or MovieClip instances are not supported in ActionScript 3.0. All scripts on object instances will be ignored.

Thanks,
Daniel.
SOLUTION
Avatar of moagrius
moagrius
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of iDeej

ASKER

Thanks for the help
@tanlihao - good catch - i didn't notice that second warning, just converted the code...

re: constants versus strings - not sure i agree it's "easier to read" - i think "enterFrame" is just as easy to understand as "Event.ENTER_FRAME" - in fact, maybe more so.  and remember, Event.ENTER_FRAME *is* a string:

"enterFrame" === Event.ENTER_FRAME

if you trace(Event.ENTER_FRAME), you'll get back "enterFrame" - so it's exactly the same thing.

that said, a lot of people agree with you, that it's a best practice to use constants, but less for readability i think, but to catch errors - e.g., "enteFrame" (missing an "r") would not give a warning, where Event.ENTE_FRAME would - so some people find that easier to debug.  i have never had that problem, but i've been doing this a long time so don't need quite as much hand-holding during debug.  note that it's also faster (more efficient) to use strings instead of constants, but only marginally so - really, it's just habit.  in the end, it's a wash and just a matter of preference.
I see.

I know they are the same because Event.ENTER_FRAME is a string constant that contains "enterFrame". I think it is easier to read because for example

MouseEvent.MOUSE_OVER
Event.ENTER_FRAME
VideoEvent.STATE_CHANGE

They are all separated into different classes but in strings they don't.

"mouseOver"
"enterFrame"
"stateChange"

Thanks for enlightening me on the second part though, never thought of that. At least now I know there is a slight performance increase, though it may not matter now or in the future, but probably when there are projects that requires as much efficiency as possible, using strings to replace will be a great idea.

Though I don't understand why there will be a performance increase, the compiler can just at compile time replace the constants with the respective strings since they won't change but anyhow I think it won't be appropriate to continue discussing about this in this thread.