Comments on: An indepth look at Flex Events

By: rahul agarwal

rahul agarwal — Thu, 10 Jun 2010 07:28:57 +0000

stop propagation and stopImmediatePropagation is good but bubble and cancalable is not properly present

By: Siraj

Siraj — Wed, 29 Jul 2009 11:53:52 +0000

Hi… many thanks for the great post… I actually have a problem with my combobox which is customized to select multiple items. The problem is, it fires multiple change events on selection change; so is there any way to stop an event already fired?
The detail is posted here: http://forums.adobe.com/thread/469331
Regards,
Siraj

By: tont0r

tont0r — Tue, 03 Mar 2009 15:04:55 +0000

Kevlin,

I could agree with you, its definitely good for web applications. Although javascript didnt come to mind first since I do have limited exposure to it. I was thinking about it being like developing a desktop application since since they run in their own little VM and just the way events are handled remind me a lot of java action listeners. Certainly a lot of less form submits than normal web applications .

By: Marcel

Marcel — Tue, 03 Mar 2009 15:00:33 +0000

Darren,

Yeah, I could have been a bit clearer about the preventDefault. Here is a good example of what I was referring to:
Check this out
Each type they type out something, it goes to the textEvent. If the text is a “\n”, it will prevent the default action, when is to display it within the input box.

Hope that helps!

By: Kelvin Luck

Kelvin Luck — Tue, 03 Mar 2009 07:29:24 +0000

It’s interesting you say that the flash event model makes it similar to developing desktop applications… To me it makes it more similar to developing web applications – it’s basically the W3C event model which has been available in web browsers through javascript for years…

By: Darren

Darren — Mon, 02 Mar 2009 22:46:18 +0000

This bit doesn’t make a lot of sense to me, “One example is the MouseEvent.DOUBLE_CLICK event. When you fire this event, it will highlight the string that the mouse is hovering over.” Highlight the string? I guess you mean the label or the UITextField of a standard Button? It doesn’t seem to make any changes to this for me either. It just briefly shows the downSkin which effectively changes the background colour of the button.

@ Justin, I find it easiest to create a custom event with weakReferences set to true and extend this for all my other events. Easier than writing out all those extra parameters every time just to set the fifth one to true when you usually only need the first two. You can add a generic data Object to this event too to make it more useful, or just extend DynamicEvent for your custom event.

By: An indepth look at Flex Events | Switch on the Code

An indepth look at Flex Events | Switch on the Code — Mon, 02 Mar 2009 16:10:08 +0000

[...] An indepth look at Flex Events Source: Code of Doom Excerpt: [...]

By: Justin Reidy

Justin Reidy — Mon, 02 Mar 2009 14:56:53 +0000

You forgot my favorite / most used event argument – useWeakReferences! Events default to using Strong references to listeners, which means that you can have situations in which you lose your named reference to the host of a listener, thus preventing you from removing the event listener. The listener floats around in memory, never to be garbage collected, because of the strong reference. Setting useWeakReferences to true avoids this potential problem. There are a couple of situations where you’d want to be careful with weak references, though – most notably in the case of using an anonymous function as your listener, since a weak reference would garbage collect the function before it is called!

David Coletta has some good points here: http://www.colettas.org/?p=115

By: Marcel

Marcel — Mon, 02 Mar 2009 14:52:55 +0000

bob,

When it comes to removing events, really the main thing you have to be concerned with is when you are no longer going to use that object. If it is just a button that you are going to be using throughout the lifetime of the application and you are only creating that button once, then no worries. You can leave it there. The example I used was when people make the mistake of adding them within something like commitProperties, which gets called multiple times on the same object. Another example is within item renderers. If you are going to set your object up where event listeners are added multiple times, please be aware that they may add up .

Hope that helps!

By: burritobob

burritobob — Mon, 02 Mar 2009 10:42:12 +0000

good writeup. Concerning the removing of listeners. Lets say for example I have a set up a listener onRegister, for when a button gets clicked. So in the function that handles the event, I should remove the listener ? Where do I re register to associate the listener with the button , in the same function ?. thanks