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
