Re: [Flashcoders] Passing vars with the the timer and events
Oh man, thank you for this example!
This totally blows me away. I am sorry I was so persistent. You are correct.
I will have to check all my applications now, hehe.
This also means that all my earlier arguments are incorrect and that the use
of Delegate is indeed very dangerous.
Thank you for showing this to me! To me this really is unexpected
behaviour... I just can not believe that this is designed behaviour...
Greetz Erik
On 3/13/08, Cory Petosky [EMAIL PROTECTED] wrote:
There is no such thing as a reference to be created invisibly within
the event system.
I disagree. Try this test code:
package {
import flash.events.Event;
import flash.display.Sprite;
import flash.utils.getTimer;
public class TestClass extends Sprite {
public function TestClass() {
trace(Started!);
var s:Sprite = new Sprite();
s.addEventListener(Event.ENTER_FRAME, listener);
addEventListener(Event.ENTER_FRAME, listener);
}
private function listener(event:Event):void {
trace(event.currentTarget.toString() +
getTimer());
}
}
}
You'll see both event handlers fire until the end of time. Event
references actually are kept, invisibly, within the event system.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
Hey there,
I was totally shocked this morning. If what you were saying was true it
would mean that if you created a class with a listener to itself and
instantiated it, it would never be garbage collected.
So I did some extra tests.
1. Your example with a weak listener (same result)
2. Trying to force garbage collection using System.gc and the
localconnection 'hack' (same result)
So I turned to the Flex Profiler. I used the following class to test things:
package
{
import flash.display.Sprite;
import flash.events.Event;
import flash.system.System;
import flash.text.TextField;
[SWF(frameRate=1)]
public class testAS extends Sprite
{
private var _t:TextField;
private var _c:uint;
private var _a:Array;
public function testAS()
{
_a = new Array();
_t = new TextField();
addChild(_t);
var a:SpriteClass = new SpriteClass();
a.addEventListener(Event.ENTER_FRAME, _handler);
};
private function _handler(e:Event):void
{
_t.text = (_c++).toString();
_a.push(new Counter());
};
};
};
Initialy the profiler showed the behaviour you were describing. However, if
I pressed
the Run Garbage Collector button, the instance of SpriteClass was
removed. This indicates the behaviour that I described in my example.
I changed the above example to use a weak listener. The instance of
SpriteClass was only removed after I clicked the Run garbage
collector button.
In the handler I removed the listener to the SpriteClass instance. The
instance of SpriteClass was only removed from memory after I clicked
the Run garbage collector button.
If I run the profiler with the
option Generate object allocation stack traces, the instance is
removed everytime quite fast.
The conclusion of all this is that my statement in previous emails was
correct. What your example shows is that while the instance _can_ be garbage
collected, you will never know when it actually will.
A summary:
- There is no such thing as a reference to be created invisibly within the
event system.
- You can not be sure when an instance is garbage collected.
- Weak references only indicate that: if the reference on the dispatcher
object to the listener is the last one, the instance containing the listener
will me available for garbage collection.
I want to thank you Cory for being as persistent as I can be. It enabled me
to do extensive tests to see
how the player works. In my tests in a standalone player there were
cases where I let the example application run for more then half an
hour without garbage collection of SpriteClass. I am not sure when the
garbage collector kicks in (might be triggered by total memory usage).
I will continue to monitor the
example
to see if the instance will ever be garbage collected. If not, I will
file a bug at adobe.
Greetz Erik
On 3/14/08, EECOLOR [EMAIL PROTECTED] wrote:
Oh man, thank you for this example!
This totally blows me away. I am sorry I was so persistent. You are
correct. I will have to check all my applications now, hehe.
This also means that all my earlier arguments are incorrect and that the
use of Delegate is indeed very dangerous.
Thank you for showing this to me! To me this really is unexpected
behaviour... I just can not believe that this is designed behaviour...
Greetz Erik
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
I have modified my test classes slightly. And found that when debugging this
movie in Flex Builder 3, the garbage collection was triggered when I moved
my mouse within the Flash movie.
I suspect that the method behind the screens that runs the garbage collector
is quite complex. I think that in more complex applications garbage
collection is more efficient.
Counter.as
package
{
import flash.display.BitmapData;
public class Counter
{
public var bmd:BitmapData;
public function Counter()
{
bmd = new BitmapData(500, 500);
bmd.noise(Math.random() * 100);
};
};
};
SpriteClass.as
package
{
import flash.display.Sprite;
public class SpriteClass extends Sprite
{
public function SpriteClass()
{
};
};
};
testAS.as
package
{
import flash.display.Sprite;
import flash.events.Event;
import flash.text.TextField;
[SWF(frameRate=4)]
public class testAS extends Sprite
{
private var _t:TextField;
private var _c:uint;
private var _a:Array;
public function testAS()
{
_a = new Array();
_t = new TextField();
addChild(_t);
var a:SpriteClass = new SpriteClass();
a.addEventListener(Event.ENTER_FRAME, _handler);
};
private function _handler(e:Event):void
{
_t.text = _c.toString();
_a.push(new Counter());
_c++;
if (_c 300)
{
(e.currentTarget as SpriteClass).removeEventListener(
Event.ENTER_FRAME, _handler);
};
};
};
};
Greetz Erik
On 3/14/08, EECOLOR [EMAIL PROTECTED] wrote:
Hey there,
I was totally shocked this morning. If what you were saying was true it
would mean that if you created a class with a listener to itself and
instantiated it, it would never be garbage collected.
So I did some extra tests.
1. Your example with a weak listener (same result)
2. Trying to force garbage collection using System.gc and the
localconnection 'hack' (same result)
So I turned to the Flex
Profiler. I used the following class to test things:
package
{
import flash.display.Sprite;
import flash.events.Event;
import flash.system.System;
import flash.text.TextField;
[SWF(frameRate=1)]
public class testAS extends Sprite
{
private var _t:TextField;
private var _c:uint;
private var _a:Array;
public function testAS()
{
_a = new Array();
_t = new TextField();
addChild(_t);
var a:SpriteClass = new SpriteClass();
a.addEventListener(Event.ENTER_FRAME, _handler);
};
private function _handler(e:Event):void
{
_t.text = (_c++).toString();
_a.push(new Counter());
};
};
};
Initialy the profiler showed the behaviour you were describing. However,
if I pressed
the Run Garbage Collector button, the instance of SpriteClass was removed.
This indicates the behaviour that I described in my example.
I changed the above example to use a weak listener. The instance of
SpriteClass was only removed after I clicked the Run garbage collector
button.
In the handler I removed the listener to the SpriteClass instance. The
instance of SpriteClass was only removed from memory after I clicked
the Run garbage collector button.
If I run the profiler with the
option Generate object allocation stack traces, the instance is removed
everytime quite fast.
The conclusion of all this is that my statement in previous emails was
correct. What your example shows is that while the instance _can_ be garbage
collected, you will never know when it actually will.
A summary:
- There is no such thing as a reference to be created invisibly within
the event system.
- You can not be sure when an instance is garbage collected.
- Weak references only indicate that: if the reference on the dispatcher
object to the listener is the last one, the instance containing the listener
will me available for garbage collection.
I want to thank you Cory for being as persistent as I can be. It enabled
me to do extensive tests to see
how the player works. In my tests in a standalone player there were cases
where I let the example application run for more then half an hour without
garbage collection of SpriteClass. I am not sure when the garbage collector
kicks in (might be triggered by total memory usage). I will continue to
monitor the
example
to see if the instance will ever be garbage collected. If not, I will file a
bug at adobe.
Greetz Erik
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
Old articles, but a must read: http://gskinner.com/blog/archives/2006/06/as3_resource_ma.html http://gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html http://gskinner.com/blog/archives/2006/06/understanding_t.html http://gskinner.com/blog/archives/2006/07/as3_weakly_refe.html - Original Message - From: EECOLOR [EMAIL PROTECTED] To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Friday, March 14, 2008 1:18 PM Subject: Re: [Flashcoders] Passing vars with the the timer and events I have modified my test classes slightly. And found that when debugging this movie in Flex Builder 3, the garbage collection was triggered when I moved my mouse within the Flash movie. I suspect that the method behind the screens that runs the garbage collector is quite complex. I think that in more complex applications garbage collection is more efficient. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
Erik, Thanks for being more diligent than I was! I assumed the let it run for an hour while eating dinner test case was enough, too! This behavior is much more sane than my initial assessment, and I'm certainly glad to have been shown incorrect. :) On 3/14/08, Muzak [EMAIL PROTECTED] wrote: Old articles, but a must read: http://gskinner.com/blog/archives/2006/06/as3_resource_ma.html http://gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html http://gskinner.com/blog/archives/2006/06/understanding_t.html http://gskinner.com/blog/archives/2006/07/as3_weakly_refe.html - Original Message - From: EECOLOR [EMAIL PROTECTED] To: Flash Coders List flashcoders@chattyfig.figleaf.com Sent: Friday, March 14, 2008 1:18 PM Subject: Re: [Flashcoders] Passing vars with the the timer and events I have modified my test classes slightly. And found that when debugging this movie in Flex Builder 3, the garbage collection was triggered when I moved my mouse within the Flash movie. I suspect that the method behind the screens that runs the garbage collector is quite complex. I think that in more complex applications garbage collection is more efficient. ___ 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
Re: [Flashcoders] Passing vars with the the timer and events
That's a dangerous practice. I do not completely agree. It prevents you from using weak event listeners Correct. The common use for weak event listeners is when adding listeners to the stage: the stage is allways present and adding normal listeners to it will insure that the listener will persist. Even if it is removed everywhere else. In most cases there is actually no real benefit of creating weak event listeners. In most cases parents add listeners to their children. Children are removed and that's that. If the parent gets removed: no problem. In the majority of the cases, the creation of listeners on a parent is bad practice (stage is one of those exceptions). 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! Hmmm, if it was garbage collected, why would I remove the listener, isnt that the point of weak references? Greetz Erik 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. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
The common use for weak event listeners is when adding listeners to the stage I disagree. Weak event listeners should be used in nearly all cases. In most cases there is actually no real benefit of creating weak event listeners. In most cases parents add listeners to their children. Children are removed and that's that. This is not correct. If you add a normal event listener to a child, and then remove that child, the child is _not_ garbage collected. Objects are only garbage collected when all references to the object are removed. Adding a normal event listener causes a reference to be created invisibly within the event system. You must remove all normal listeners from an object before it will be garbage collected. Hmmm, if it was garbage collected, why would I remove the listener, isnt that the point of weak references? You can't use weak references on an anonymous event listener. The only reference to that function is in the event system itself, so if you use a weak reference, the garbage collector considers the anonymous function eligible for garbage collection. Thus, the garbage collector removes your event listener immediately, and you never get your event. (When I say immediately, I really mean at a random time when the GC is invoked. Sometimes that's immediate, sometimes its not, but you should assume immediacy so your code doesn't randomly break.) On 3/13/08, EECOLOR [EMAIL PROTECTED] wrote: That's a dangerous practice. I do not completely agree. It prevents you from using weak event listeners Correct. The common use for weak event listeners is when adding listeners to the stage: the stage is allways present and adding normal listeners to it will insure that the listener will persist. Even if it is removed everywhere else. In most cases there is actually no real benefit of creating weak event listeners. In most cases parents add listeners to their children. Children are removed and that's that. If the parent gets removed: no problem. In the majority of the cases, the creation of listeners on a parent is bad practice (stage is one of those exceptions). 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! Hmmm, if it was garbage collected, why would I remove the listener, isnt that the point of weak references? Greetz Erik 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. ___ 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
Re: [Flashcoders] Passing vars with the the timer and events
If you add a normal event listener to a child,
and then remove that child, the child is _not_ garbage collected.
Objects are only garbage collected when all references to the object
are removed. Adding a normal event listener causes a reference to be
created invisibly within the event system.
I think this is where we disagree. If a parent adds a listener to a child,
this means the child has a reference to the parent, not the other way
around. What you call the event system can be thought of as an array
with handler methods on the child instance. This means that if you add
a normal event listener to a child and then remove it, it will be
garbage collected. There is no such thing as a
reference to be created invisibly within the event system.
You can't use weak references on an anonymous event listener.
In my last email I agreed with you on this :)
You must remove all normal listeners from an object before it will be
garbage collected.
Again, I do not think this is correct. An object will be garbage collected
if there are no references to it. Adding listeners to an object will not
create references to the object itself.
An example (not usefull, but to illustrate the point):
package
{
class TestClass
{
public function TestClass()
{
var o:EventDispatcher = new EventDispatcher();
o.addEventListener(Event.COMPLETE, _handler);
}; // At this point o will be marked for
garbage collection, no references to o left.
private function _handler(e:Event):void
{
};
};
};
Another example (again not usefull, but to illustrate the point):
package
{
class TestHandler
{
public function TestHandler()
{
};
public function handler(e:Event):void
{
};
};
};
package
{
import flash.display.Sprite;
class TestClass extends Sprite
{
public function TestClass()
{
var o:TestHandler = new TestHandler();
stage.addEventListener(Event.RESIZE, o.handler);
}; // At this point o will not be marked for garbage collection, stage
will still have a reference to it.
};
};
I hope you agree on this. If not I am open to convincing arguments :)
Greetz Erik
On 3/13/08, Cory Petosky [EMAIL PROTECTED] wrote:
The common use for weak event
listeners is when adding listeners to the stage
I disagree. Weak event listeners should be used in nearly all cases.
In most cases there is actually no real benefit of creating weak event
listeners. In most cases parents add
listeners to their children. Children are removed and that's that.
This is not correct. If you add a normal event listener to a child,
and then remove that child, the child is _not_ garbage collected.
Objects are only garbage collected when all references to the object
are removed. Adding a normal event listener causes a reference to be
created invisibly within the event system.
You must remove all normal listeners from an object before it will be
garbage collected.
Hmmm, if it was garbage collected, why would I remove the listener, isnt
that the point of weak references?
You can't use weak references on an anonymous event listener. The only
reference to that function is in the event system itself, so if you
use a weak reference, the garbage collector considers the anonymous
function eligible for garbage collection. Thus, the garbage collector
removes your event listener immediately, and you never get your event.
(When I say immediately, I really mean at a random time when the GC
is invoked. Sometimes that's immediate, sometimes its not, but you
should assume immediacy so your code doesn't randomly break.)
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
There is no such thing as a reference to be created invisibly within the
event system.
I disagree. Try this test code:
package {
import flash.events.Event;
import flash.display.Sprite;
import flash.utils.getTimer;
public class TestClass extends Sprite {
public function TestClass() {
trace(Started!);
var s:Sprite = new Sprite();
s.addEventListener(Event.ENTER_FRAME, listener);
addEventListener(Event.ENTER_FRAME, listener);
}
private function listener(event:Event):void {
trace(event.currentTarget.toString() + getTimer());
}
}
}
You'll see both event handlers fire until the end of time. Event
references actually are kept, invisibly, within the event system.
On 3/13/08, EECOLOR [EMAIL PROTECTED] wrote:
If you add a normal event listener to a child,
and then remove that child, the child is _not_ garbage collected.
Objects are only garbage collected when all references to the object
are removed. Adding a normal event listener causes a reference to be
created invisibly within the event system.
I think this is where we disagree. If a parent adds a listener to a child,
this means the child has a reference to the parent, not the other way
around. What you call the event system can be thought of as an array
with handler methods on the child instance. This means that if you add
a normal event listener to a child and then remove it, it will be
garbage collected. There is no such thing as a
reference to be created invisibly within the event system.
You can't use weak references on an anonymous event listener.
In my last email I agreed with you on this :)
You must remove all normal listeners from an object before it will be
garbage collected.
Again, I do not think this is correct. An object will be garbage collected
if there are no references to it. Adding listeners to an object will not
create references to the object itself.
An example (not usefull, but to illustrate the point):
package
{
class TestClass
{
public function TestClass()
{
var o:EventDispatcher = new EventDispatcher();
o.addEventListener(Event.COMPLETE, _handler);
}; // At this point o will be marked for
garbage collection, no references to o left.
private function _handler(e:Event):void
{
};
};
};
Another example (again not usefull, but to illustrate the point):
package
{
class TestHandler
{
public function TestHandler()
{
};
public function handler(e:Event):void
{
};
};
};
package
{
import flash.display.Sprite;
class TestClass extends Sprite
{
public function TestClass()
{
var o:TestHandler = new TestHandler();
stage.addEventListener(Event.RESIZE, o.handler);
}; // At this point o will not be marked for garbage collection, stage
will still have a reference to it.
};
};
I hope you agree on this. If not I am open to convincing arguments :)
Greetz Erik
On 3/13/08, Cory Petosky [EMAIL PROTECTED] wrote:
The common use for weak event
listeners is when adding listeners to the stage
I disagree. Weak event listeners should be used in nearly all cases.
In most cases there is actually no real benefit of creating weak event
listeners. In most cases parents add
listeners to their children. Children are removed and that's that.
This is not correct. If you add a normal event listener to a child,
and then remove that child, the child is _not_ garbage collected.
Objects are only garbage collected when all references to the object
are removed. Adding a normal event listener causes a reference to be
created invisibly within the event system.
You must remove all normal listeners from an object before it will be
garbage collected.
Hmmm, if it was garbage collected, why would I remove the listener, isnt
that the point of weak references?
You can't use weak references on an anonymous event listener. The only
reference to that function is in the event system itself, so if you
use a weak reference, the garbage collector considers the anonymous
function eligible for garbage collection. Thus, the garbage collector
removes your event listener immediately, and you never get your event.
(When I say immediately, I really mean at a random time when the GC
is invoked. Sometimes that's immediate, sometimes its not, but you
should assume immediacy so your code doesn't randomly break.)
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
[Flashcoders] Passing vars with the the timer and events
I have a custom TimerEvent that I am using to pass some
information when the timer is up. My issue is that I dont need to pass the
information until the time is up but how can i pass the information to a
timer that is not available yet?
The basic setup is something like this:
public function myFunc ( varToPass : String, delay :
Number = 0 )
{
if ( delay 0 )
{
globalTimer = new Timer ( delay, 1)
globalTimer.start();
globalTimer.addEventListener (
TimerEvent.Timer, timerEventHandler)
} else {
dispatchEvent ( new SoundTimerEvent (
SoundTimerEvent.PLAY_VO , _sound ) ) ;
}
}
private function timeEventHandler ( te : TimerEvent )
{
// More stuff here
}
if no delay is added the event gets dispatched properly
and everything moves great but how would I add or pass a variable through
the globalTimer so that when the timer is up I can catch the _sound
property?
Any ideas?
TIA
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
Hi Helmut,
One option is extending Timer such that it dispatches your custom
SoundTimerEvent rather than the built in TimerEvent.
Another option, if _sound is a class var, would be to have your
timeEventHandler dispatch the SoundTimerEvent.
hth,
Bob
Helmut Granda wrote:
I have a custom TimerEvent that I am using to pass some
information when the timer is up. My issue is that I dont need to pass the
information until the time is up but how can i pass the information to a
timer that is not available yet?
The basic setup is something like this:
public function myFunc ( varToPass : String, delay :
Number = 0 )
{
if ( delay 0 )
{
globalTimer = new Timer ( delay, 1)
globalTimer.start();
globalTimer.addEventListener (
TimerEvent.Timer, timerEventHandler)
} else {
dispatchEvent ( new SoundTimerEvent (
SoundTimerEvent.PLAY_VO , _sound ) ) ;
}
}
private function timeEventHandler ( te : TimerEvent )
{
// More stuff here
}
if no delay is added the event gets dispatched properly
and everything moves great but how would I add or pass a variable through
the globalTimer so that when the timer is up I can catch the _sound
property?
Any ideas?
TIA
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
--
Thanks,
~
Bob Leisle
Headsprout Software Engineering
http://www.headsprout.com
Where kids learn to read!
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
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!!
On 3/12/08, Bob Leisle [EMAIL PROTECTED] wrote:
Hi Helmut,
One option is extending Timer such that it dispatches your custom
SoundTimerEvent rather than the built in TimerEvent.
Another option, if _sound is a class var, would be to have your
timeEventHandler dispatch the SoundTimerEvent.
hth,
Bob
Helmut Granda wrote:
I have a custom TimerEvent that I am using to pass
some
information when the timer is up. My issue is that I dont need to pass
the
information until the time is up but how can i pass the information to a
timer that is not available yet?
The basic setup is something like this:
public function myFunc ( varToPass : String, delay :
Number = 0 )
{
if ( delay 0 )
{
globalTimer = new Timer ( delay, 1)
globalTimer.start();
globalTimer.addEventListener (
TimerEvent.Timer, timerEventHandler)
} else {
dispatchEvent ( new SoundTimerEvent (
SoundTimerEvent.PLAY_VO , _sound ) ) ;
}
}
private function timeEventHandler ( te : TimerEvent
)
{
// More stuff here
}
if no delay is added the event gets dispatched
properly
and everything moves great but how would I add or pass a variable
through
the globalTimer so that when the timer is up I can catch the _sound
property?
Any ideas?
TIA
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
--
Thanks,
~
Bob Leisle
Headsprout Software Engineering
http://www.headsprout.com
Where kids learn to read!
___
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
Re: [Flashcoders] Passing vars with the the timer and events
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
Re: [Flashcoders] Passing vars with the the timer and events
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
Re: [Flashcoders] Passing vars with the the timer and events
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
RE: [Flashcoders] Passing vars with the the timer and events
Haven't followed this thread, and don't even know what the original question is other than the thread title, but I'll just jump in and add, I don't think attaching variables to events is a good idea anymore, I used to do it in AS2 all the time with Delegate, but now with the new AS2 event model, I think a better approach is to dispatch and listen for events, and grab properties from other places in your code when the event is heard - use event.target as necessary and such. You can even attach properties to the target instead of to the event, so event.target.myProperty and the like. Jason Merrill Bank of America GTO LLD Solutions Design Development eTools Multimedia Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal GTO Innovative Learning Blog subscribe. ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Passing vars with the the timer and events
Thanks Jason, That is how I approached in the end. I was just getting stuck while dispatching custom events from the extended Timer class. but I think all is solved now. On 3/12/08, Merrill, Jason [EMAIL PROTECTED] wrote: Haven't followed this thread, and don't even know what the original question is other than the thread title, but I'll just jump in and add, I don't think attaching variables to events is a good idea anymore, I used to do it in AS2 all the time with Delegate, but now with the new AS2 event model, I think a better approach is to dispatch and listen for events, and grab properties from other places in your code when the event is heard - use event.target as necessary and such. You can even attach properties to the target instead of to the event, so event.target.myProperty and the like. Jason Merrill Bank of America GTO LLD Solutions Design Development eTools Multimedia Bank of America Flash Platform Developer Community Are you a Bank of America associate interested in innovative learning ideas and technologies? Check out our internal GTO Innovative Learning Blog subscribe. ___ 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
