I was a little bit concerned about the Delegate approach and I was able to figure out that extending the Timer class and adding a property to to the new class everything worked fine. My issue was that once the handler the extended timer class was casted to Timer rather than my custom class, so I was able to overcome that by doing the following:
var tmr:SoundTimer = te.currentTarget as SoundTimer ; and now I am able to access the extra parameters added to the SoundTimer class. Now my question would be... would this approach be properly or should I still have to dispatch a customEvent for this specific feature. I know, if ain't broken, don need to fix it. :) On 3/12/08, Cory Petosky <[EMAIL PROTECTED]> wrote: > > That's a dangerous practice. It prevents you from using weak event > listeners -- because the only reference to your delegate function > object is the event listener itself, a weakly-referenced listener will > be garbage collected. Now have to manually remove your listener to > make sure your object is garbage collected -- but the only way to > remove event listeners is to pass the removeEventListener function a > reference to the function you want to remove... but you don't have > that reference! > > If it's a one-time event, you can have the listener remove itself. > Your delegate function object can pass a reference to itself (using > arguments.callee) in to the "real" event listener function, which you > can use to remove the listener. In any other case, you'll have to > build a separate data structure (usually a Dictionary of Objects -> > Functions) to keep a reference available to your code. > > > On 3/12/08, EECOLOR <[EMAIL PROTECTED]> wrote: > > If we ever he need to pass extra arguments to the handler we use a > delegate > > class to pass them. Usage: > > > > obj.addEventListener(Event.TYPE, Delegate.create(this, _handler, arg1, > > arg2)); > > > > private function _handler(e:Event, arg1:Object, arg2:Object):void > > { > > > > }; > > > > I added our delegate class as an attachment. > > > > Note that for class methods the scope (first argument of the create > method) > > has no influence. > > > > > > Greetz Erik > > > > > > > > On 3/12/08, Helmut Granda <[EMAIL PROTECTED]> wrote: > > > > > > Hi Bob, > > > > > > Thanks for the comment, that is the route that started working on > after > > > posting the question and the only issue I am having is dispatching > the > > > custom event when the timer has been reached, I did a soft search for > > > samples of extending the Timer Class with custom TimerEvents but > wasnt > > > able > > > to find any.... would you happen to know where I could find more > info? > > > > > > Thanks!! > > > > > > > > > > > _______________________________________________ > > Flashcoders mailing list > > Flashcoders@chattyfig.figleaf.com > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > > > -- > > Cory Petosky : Lead Developer : PUNY > 1618 Central Ave NE Suite 130 > Minneapolis, MN 55413 > Office: 612.216.3924 > Mobile: 240.422.9652 > Fax: 612.605.9216 > http://www.punyentertainment.com > > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > -- ...helmut _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders