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

Reply via email to