addEventListener

[Ennair]

Hi

I am trying to register this handler for the event, but I can't get it to work.

mc_light.onEnterFrame = function(){
	mc_light._alpha = mc_light._alpha - 5; 
};

mc_light.addEventListener("frameChanged", mc_light);

Any help will be very much appreciated.
E

[fx.barrett]

Ok, wait, I'm not getting what you are trying to do there.

onEnterFrame is AS 2.0 and it won't work, same goes with "_alpha"...
Try explaining what you are trying to do there.

[cresquin]

this is not Actionscript 3.0

[fx.barrett]

Ahh, if you wanted to add an enterFrame event listener to your movie clip then use something like this ( by the way, in AS 3.0 alpha goes from 0 to 1 and not from 0 to 100 as it did in AS 2.0 ).

this.mc_light.addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{
     // check if your movie clip is totally faded...
     if ( this.mc_light.alpha < 0)
     {
          // remove the listener once the movie clip is totally faded
          this.mc_light.removeEventListener(Event.ENTER_FRAME, onEnter);
          // display a message to signal once it's faded
          trace("your movie clip is now faded");
     }
     // ...if it's not totally faded, then fade it
     else
     {
          // fade the movie clip by 0.05
          this.mc_light.alpha -= .05;
     }
} // end of onEnter 

Hope that's what you were looking for.

[cresquin]

PC, i don't think your event is created properly.

mc_light.addEventListener(Event.ENTER_FRAME, onEnter); 

creates a listener on this to mc_light for Event.ENTER_FRAME. but mc_light should never dispatch Event.ENTER_FRAME.

the script should read:

addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{
     mc_light.alpha -= .05;
} // end of onEnter 

[fx.barrett]

Hmm, I do think it's best for that object to dispatch an event. Mainly because he might have multiple objects dispatching different enter frame events. Would it be more organized to have all the possible dispatch conditions in one huge function or have them structured for the specific objects.

I don't think this has anything to do with memory usage or it's not slowing down the whole application. Can't really see a clear point why can't I declare an Enter Frame event listener and assign it to a specific object.

EDIT:

addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{
     mc_light.alpha -= .05;
} // end of onEnter 

If I'm not mistaking than the code you've posted is adding an event listener to the current timeline the code is on. I don't think that's what he wanted to achieve. If you'd be so kind and explain why it's not a good practice to do so ( and why would you prefer adding the listener to the stage/timeline instead of the object, it would really be great ), what are the pros and cons, I'd really appreciate if you share your opinion/knowledge on this one.

Thanks.

[cresquin]

the eventListener declaration has to happen within the object you want to listen for the event, that's all I was trying to say.

mc_light.addEventListener(Event.ENTER_FRAME, onEnter); tells this to listen for an event from mc_light, it doesn't tell mc_light to listen for an event.

[fx.barrett]

PS: ahh, lol, sorry, I just observed that I forgot to add "mc_light" after this. Yeah, my bad, I'm a bit tired, not seeing the tiny mistakes.

[fx.barrett]

the eventListener declaration has to happen within the object you want to listen for the event, that's all I was trying to say.

mc_light.addEventListener(Event.ENTER_FRAME, onEnter); tells this to listen for an event from mc_light, it doesn't tell mc_light to listen for an event.

Ok, but what if that's exactly what he is trying to do ? Maybe he does not want "this" to listen for an event but the movie clip itself... If I can remember right then onEnterFrame was quite often used in AS 2.0 ; the only difference was that it was placed withing the object itself, on the objects timeline.

Anyways, I think I'm too tired to think straight...
Thanks for pointing those out.

[cresquin]

Yes you are correct, in AS2 you could set an onEnterframe listener from outside an object, but in AS3 if you want the movieclip itself to listen then the addEventListener needs to be declared within the movieclip.

[fx.barrett]

Ok, and wouldn't it be the same to place the enter frame listener in the movie clip or assign it from the parent timeline ? That way you'd have all the code on the main timeline and still be able to control your movies. Using yourMovie.addEventListner(Event.ENTER_FRAME, crap); would be the same with using an event listener inside the movie you are trying to control. But since you're controlling your movie from the main timeline you won't have to waste time finding a 10 times nested movie clip and editing it's event...

Maybe I'm wrong, but that's how I see it ( or does assigning an ENTER_FRAME event directly to the object behave differently then having the code inside the object ? ).

[cresquin]

Placing all of your code on the main timeline is no longer a best practice of flash. This was popularized to stop people from placing code ON objects (where it is damn near impossible to find), not within them. Code should live where it makes most sense for it to live. imagine you have 20 movieclips on stage, and you want them all to to the same or very similar things. By placing all the code on the timeline you have to code for each and every MC. If you were to encapsulate the script within a MC object in the library, you could simply place 20 instances of the MC complete with code on stage and be done.

In addition, placing a listener within a MC and creating a listener from parent to child isn't the same thing. There are some seriously confusing scope issues you'll run into doing it like that. AS3 has been built to be OOP and encapsulation is a key part of that.

[fx.barrett]

^ scope issues can be overcome. I wasn't referring to nesting, but the way it works. It essentially does the same thing either way but how you want it done, IMHO that's everyone personal choice ( like/dislike ).

Placing all of your code on the main timeline is no longer a best practice of flash.

Ok, this is something new. Never heard of a change, the whole idea was to get your code organized. I think that in then end it's up to everyone's personal style. But I really don't think that you seriously consider the "new trend" ( placing code on frames inside tons of nested movie clips ) more organized and efficient then having code on the main timeline or maybe 1-2 more timelines. Especially when you are not working alone, when you are working in a team, you can't expect each and every member to guess where you have your code, at what level and how deep it is nested.

I see lots of people saying this and that but most of their affirmations are purely of subjective nature ( same thing applies to me too when I consider placing most of the code if not all on the main timeline then nest code in N movie clips ).

Where to place the code is the subject of an infinite debate. Unless there is actually some speed loss involved or something that would affect your project's performance in a way or another I can't really see a good reason why not to use different methods.

AS 3.0 now allows users to place code only on frames, IMHO, that was brought in because of the fact that many developers got lost when having tons of code on unique objects, nested within who knows what. Placing code in nested objects, IMHO is quite the same as placing code on different objects ( unorganized, hard to follow and not a good practice... but that's just my two cents ).

Maybe in another forum we could have a nice debate/thread on this subject. We could analyze different points of views and hopefully have some serious arguments, proof that what someone is stating is actually true.

Thanks for taking the time and replying.

Cheers.

[Ennair]

Thanks very much guys for your help. I have actually read throught your posts on this thread and tried both codes. They both work which is confusing for a novice in AS3 like me, but there is a difference between the two in the number of times they seem to execute.

This code fades the mc and prints the trace message once:

this.mc_light.addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{	
	if(this.mc_light.alpha < 0){
		this.mc_light.removeEventListener(Event.ENTER_FRAME, onEnter);
		trace("mc_light is now faded");
	}
	else{
     mc_light.alpha -= .05;
	}
}

While this code also fades the mc in the same way as the previous code, but it keeps printing the trace message on and on....:

addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{
     mc_light.alpha -= .05;
} // end of onEnter

I wonder if you can please explain the difference to me? I have looked up the keyword

this

and it explained it differently than the way you guys are talking about it. I wonder if you can elaborate why you used it please?

Cheers,
E

[fx.barrett]

that is because if you only change this.mc_light.addEventListener(Event.ENTER_FRAME, onEnter); to this.addEventListener(Event.ENTER_FRAME, onEnter); and forget to change this.mc_light.removeEventListener(Event.ENTER_FRAM E, onEnter); into this.removeEventListener(Event.ENTER_FRAM E, onEnter); means that you are never removing the enter frame event listener and it will keep on firing till infinity.

[fx.barrett]

The difference between this.addEventListener(Event.ENTER_FRAME, onEnter); and this.mc_light.addEventListener(Event.ENTER_FRAME, onEnter); is that:

with this.addEventListener(Event.ENTER_FRAME, onEnter); you add the listener to the current timeline the code is on, meaning "this" timeline.

with this.mc_light.addEventListener(Event.ENTER_FRAME, onEnter); you are looking on the current timeline ( on "this" timeline ) for an object called "mc_light" and once it finds "mc_light" in the current timeline ( this.mc_light ) it adds the listener to the object and not to the timeline.

We had a "tiny" debate on this in the upper posts.

[Ennair]

Thanks for that I understand what you mean now.
How about when if we don't use this? Because the code below works too!

addEventListener(Event.ENTER_FRAME, onEnter);

function onEnter(event:Event):void
{	
	if(mc_light.alpha < 0){
		removeEventListener(Event.ENTER_FRAME, onEnter);
		trace("mc_light is now faded");
	}
	else{
     mc_light.alpha -= .05;
	}
}

[fx.barrett]

^ That's the same thing as if we would be using "this". If you use the code that way, without defining a path to a certain object or assigning it to a certain object then by default Flash refers to "this".

It's not a must to use "this", but I like using it because I feel that it makes the code easier to understand. But as I said, it's not a must to use "this".

[cresquin]

Where to place the code is the subject of an infinite debate. Unless there is actually some speed loss involved or something that would affect your project's performance in a way or another I can't really see a good reason why not to use different methods.

Well, for very small projects/animations I'll stipulate that code on the timeline is ok, but the new best practice is to use AS3 as OOP and separate your code out into reusable chunks (classes). Then import the code you need as you need it.

[cresquin]

^ That's the same thing as if we would be using "this". If you use the code that way, without defining a path to a certain object or assigning it to a certain object then by default Flash refers to "this".

It's not a must to use "this", but I like using it because I feel that it makes the code easier to understand. But as I said, it's not a must to use "this".

"this" was required in AS1, then not required but allowed in AS2 and 3. in AS2 one thing "this" was good for was that if you were running a function from a different object, the this keyword helped to differentiate the scope of the variables you were working with. Using "this" caused the function to use the variable from the object where the function was called, leaving "this" used either variables defined within the funciton or variables from the object where the function was defined.

There are a lot of scpoe issues like this that have been cleared up in AS3, I'm not sure if this is one of them.

in most cases, "this" just helps differentiate between variables scoped to the function and variables scoped to the object.