Re: [Flashcoders] Passing vars with the the timer and events

2008-03-14 Thread EECOLOR
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

2008-03-14 Thread EECOLOR
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

2008-03-14 Thread EECOLOR
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

2008-03-14 Thread Muzak

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

2008-03-14 Thread Cory Petosky
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

2008-03-13 Thread EECOLOR
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

2008-03-13 Thread Cory Petosky
  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

2008-03-13 Thread EECOLOR
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

2008-03-13 Thread Cory Petosky
 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
  

Re: [Flashcoders] Passing vars with the the timer and events

2008-03-12 Thread Bob Leisle

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

2008-03-12 Thread Helmut Granda
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

2008-03-12 Thread EECOLOR
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

2008-03-12 Thread Cory Petosky
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

2008-03-12 Thread Helmut Granda
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

2008-03-12 Thread Merrill, Jason
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

2008-03-12 Thread Helmut Granda
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