EventDispatcher interface

[4xy <wo...@gmail.com>]

Hi folks,
Firsty I would like to say thank you for providing the stuff. I'am using
Flex for a several years and every time I encouter EventDispatcher object I
fill sad due to this.
As for me I would extend the inteface of this entity.At present we have 
addEventListener(eventType, Listener) removeEventListener(eventType,
Listener)
Every parameter is mandatory. But why don't we have those?
removeAllEventListeners()removeEventListener(eventType, Listener = null) 
The last one removes all the listeners of the given type. May be you will
consider the extension of EventDispatcher by adding those methods to
IEventDispatcher? (even stay compatible with the existing code)
Current interface excludes the right usage (I mean clean up listeners) of
the case where actual listeners decorated by some proxy listener function
e.g.
private function proxy(listener: Function): Function{  function
onEvent(event: Event): void  {    if (_ignoredEvents.indexOf(event.type) ==
-1)    {      _events.push(event);    }    if (listener != null) {
listener(event); }  }  return
onEvent;}...eventProducer.addEventListener(Event.EVENT_NAME,
proxy(listener));
What would you say?




--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/EventDispatcher-interface-tp10406.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.

Re: EventDispatcher interface

[Mihai Chira <mi...@gmail.com>]

> As for me I would extend the inteface of this entity.
We cannot, because both EventDispatcher is part of airglobal.swc, and
IEventDispatcher part of playerglobal.swc, which means we don't have
control over their interfaces.


> But why don't we have those?
> removeAllEventListeners()removeEventListener(eventType, Listener = null)
They would be nice, but barring that possibility, I think the most we
could do is to create an extension of EventDispatcher (say,
FlexEventDispatcher) and to use it wherever we now create an instance
of EventDispatcher (right now in 7 places in the SDK) or extend
EventDispatcher (at least 80 places). But I would go for a gradual
implementation (partly because it would increase memory consumption,
having to hold the listeners in a dictionary), in the places which
make most sense (e.g. UI controls which already have multiple
listeners in the SDK for the same event type).
I like the idea, and it wouldn't be that difficult to start, and see
how it goes. Maybe you'd like to create a patch for it?

RE: EventDispatcher interface

[Kessler CTR Mark J <ma...@usmc.mil>]

    I made an example[1] a while back when I was playing with that.  It involves inheriting the EventDispatcher and keeping a duplicate list of events as they get added since the flash player is handling the lists and methods.

    It also enabled me to add extra functionality like single use event handlers that clean up after themselves once they run.  

   The downside is the EventDispatcher is part of the flash.events package.   Meaning it's not part of Apache Flex.  It's still in the Adobe side of the house we get from the global file we use from them.   The example below modified the FlexSprite [2] which allowed any components from that point on to gain the benefits.  If enough people wanted to have that functionality inside the FlexSprite I would take the time to finish it and commit it.


[1] http://people.apache.org/~mkessler/examples/FLEX-33608/app.swf
[2] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/core/FlexSprite.html



-Mark

-----Original Message-----
From: 4xy [mailto:workingfenix@gmail.com] 
Sent: Thursday, May 21, 2015 8:14 AM
To: users@flex.apache.org
Subject: EventDispatcher interface

Hi folks,
Firsty I would like to say thank you for providing the stuff. I'am using
Flex for a several years and every time I encouter EventDispatcher object I
fill sad due to this.
As for me I would extend the inteface of this entity.At present we have 
addEventListener(eventType, Listener) removeEventListener(eventType,
Listener)
Every parameter is mandatory. But why don't we have those?
removeAllEventListeners()removeEventListener(eventType, Listener = null) 
The last one removes all the listeners of the given type. May be you will
consider the extension of EventDispatcher by adding those methods to
IEventDispatcher? (even stay compatible with the existing code)
Current interface excludes the right usage (I mean clean up listeners) of
the case where actual listeners decorated by some proxy listener function
e.g.
private function proxy(listener: Function): Function{  function
onEvent(event: Event): void  {    if (_ignoredEvents.indexOf(event.type) ==
-1)    {      _events.push(event);    }    if (listener != null) {
listener(event); }  }  return
onEvent;}...eventProducer.addEventListener(Event.EVENT_NAME,
proxy(listener));
What would you say?




--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/EventDispatcher-interface-tp10406.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.