works when extending sprite but not eventdispatcher

[torrential]

I am trying to use an enter_frame listener in my class

addEventListener(Event.ENTER_FRAME, abc, false, 0, true);

to run

private function abc(e:Event):void

but it only works when I extend sprite. but this adds a lot of useless crap to my class and i don't know why it doesn't just work with eventdispatcher

[ASWC]

The enter frame event is dispatched by the Flash playhead and only DisplayObject can listen to it since they are the only ones concerned by the playhead. For that reason you are contradicting yourself when you affirm you need an enter frame event but don't want to deal with DisplayObject because one doesn't go without the other. If you want an object that dispatches event at regular interval and that is not a DisplayObject then use the Timer class.

[torrential]

isn't timer possibly asynchronous?

[ASWC]

If you mean that a Timer cannot rigorously follow the same rate than the enter frame event, that is correct. It can be set equal to the frame rate but the frame rate can slow down once in a while in which case the timer will be off syncro. If enter frame is really the only regular event type you want to work with but you don't want to extend a DisplayObject class you could instead use the composition pattern and create an internal object that can register enter frame (private var enterframedispatcher:Sprite) or maybe cleaner pass a reference to the stage in your class constructor and register your enter frame event on it.

[torrential]

Yes, that is what I meant by asynchronous but did not know the right word (my English is not perfect). I am trying to create a sound fading function which requires lowering volume of something over time.

[ASWC]

Fading sound? Then why does it have to be in sync with the frame rate? Alternatively you can take a look at this page where I show a SoundManager class that can do this and much more.

[torrential]

wasn't able to look at the fading source code.

anyways though, because if i do it by timer there is a chance it won't fade out fast enough and result in ugly overlap

[lordofduct]

won't fade out fast enough???

It will fade out as fast as you set the Timer for. If the Timer is to slow, reduce the time.

If it's because the animation is frame dependent (which it shouldn't be, animate to time, it's more predictable), well than listen to the ENTER_FRAME event of some dependent object... maybe the object you need to sync to!?

You could even tie it directly to that animated DisplayObject by having a property tell you how close it is to being finished (a percentage value), and just the fade of the audio to that. When it's done, the audio will be done.

[Mazoonist]

Originally Posted by torrential

i don't know why it doesn't just work with eventdispatcher

The way it really works is that you can only add event listeners to objects that dispatch those same events. The EventDispatcher class isn't programmed to dispatch ENTER_FRAME events. But somewhere in the DisplayObject class definition (that we don't get to see, except in the documentation), the DisplayObject class is actively dispatching ENTER_FRAME events. And therefore, so is any class that inherits from DisplayObject, for example: Sprite.

(The one exception to the above rule about only being able to add event listeners to the same objects that dispatch them has to do with events that "bubble" up the display list, in which case you can add an event listener to a display object container for an event that is dispatched by one of its children).

Of course, you can add any event listener you want to any object that extends EventDispatcher (and therefore has an addEventListener method), and you won't get any errors. It will just fail silently if the object doesn't also dispatch that event (as programmed by its class).

[Mazoonist]

I was going to suggest just extending DisplayObject instead of Sprite or EventDispatcher. But I just tried it, and it failed. Doing some online research, I learned that while you can write your own class that extends DisplayObject, you get an error when you try to instantiate it.

I find this interesting. Perhaps this is a side issue (and sorry for the digression), but I kind of wonder how they enforce this--that they can somehow extend DisplayObject, but we can't. I wonder what that code looks like.