Extend the list and add Event metadata of the additional events you want the
item renderers to dispatch.
Here's an example of a custom TileList I'm currently using in a project.
[Event(name="imageClick",
type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
[Event(name="watch", type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
[Event(name="visit", type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
[Event(name="follow", type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
[Event(name="unfollow",
type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
[Event(name="download",
type="be.gip.twitch.multiviewer.events.TwitchListEvent")]
public class TwitchTileList extends TileList {
}
The TwitchListEvent then has constants for all these event types.
public static const IMAGE_CLICK:String = "imageClick";
public static const WATCH:String = "watch";
public static const VISIT:String = "visit";
public static const FOLLOW:String = "follow";
public static const UNFOLLOW:String = "unfollow";
public static const DOWNLOAD:String = "download";
The custom event extends ListEvent and also "carries" the index of the item (selectedIndex) that dispatched the event as the custom
list itself is not selectable.
To determine the index from within the item renderer, I use the following.
private function getItemIndex():int {
var list:ListBase = owner as ListBase;
return list.itemRendererToIndex(this);
}
I also dispatch the event on the item renderers "owner" - data typed as
ListBase - rather than using bubbling.
private function dispatchTwitchEvent(type:String):void {
var idx:int = getItemIndex();
var evt:TwitchListEvent = new TwitchListEvent(type);
evt.itemRenderer = this;
evt.index = idx;
owner.dispatchEvent(evt);
}
If you want to get rid of the visual selection of an item in a list control, look into overriding the following methods and have
them return nothing:
drawHighlightIndicator
drawSelectionIndicator
regards,
Peter Ginneberge
----- Original Message -----
From: "Thomas Wright" <twri...@yesco.com>
To: <dev@flex.apache.org>; "Jeffry Houser" <jef...@dot-com-it.com>
Sent: Friday, October 11, 2013 5:23 PM
Subject: Re: Garbage Collection Concern
So - now, after attempting to add some event handlers here, I remember why
I did what I did.
How on earth do you dispatch events from itemrenderers, and successfully
add handlers dynamically to the view?
First off, the mxml for the list is such that you merely indicate the class
to be utilized as an event handler so there's no way to actually add an
event handler (at least that I can see) for working object.
Second, handler's would need to be dynamically created and destroyed as
itemrenderers are created and destroyed - but if I can't access the working
objects as they're being created.
I mean, I guess I can listen for the creation of the ir object from the
list, and then add an event handler - but still, even if I do that, it
seems I can only add the handler to the list class - but it's the list
class. Do I need to extend it? No - I guess I can reference it, add a
handler, then point the handler to the view? If so, that's still doing the
same thing I was doing before. I'm calling a function of a parent class
from within a child.
This is starting to sound much more complicated than I'd imagine it should
be.
Is there an easy way round these issues? Am I missing the point? I found a
few "suggestions" on stackoverflow - but they're just as hacky as anything
I've tried or thought of.
On Thu, Oct 10, 2013 at 10:19 AM, Thomas Wright <twri...@yesco.com> wrote:
Ok, thanks.
I can't remember why I even started doing this in the first place -
honestly.
I do remember having problems with dispatching an event in one particular
circumstance, so I did this and didn't look back.
Bad habits die hard I guess.
Thanks for the response :)
On Thu, Oct 10, 2013 at 9:24 AM, Jeffry Houser <jef...@dot-com-it.com>wrote:
On 10/10/2013 11:14 AM, Thomas Wright wrote:
Second - is there a better way to handle this, or is this legit?
From an encapsulation perspective, the renderer shouldn't know its
parents.
I always recommend dispatching an event, that bubbles from the renderer
and then handling it in the component that contains the list.
In terms of memory management; I'm not sure though. With your approach
you are creating a dependency on the list itemRenderer to its parent two
levels up.
By using events that bubble, you are not creating that dependency.
--
Jeffry Houser
Technical Entrepreneur
http://www.jeffryhouser.com
203-379-0773
--
*Thomas Wright*
Software Engineer
Extension: 1054
Office: [801] 464.4600
Corporate Division
twri...@yesco.com
--
*Thomas Wright*
Software Engineer
Extension: 1054
Office: [801] 464.4600
Corporate Division
twri...@yesco.com
