I have a custom component on which I have bound an array collection to one of its proeprties:
<comp:MyComp id="comp" prop="{images}" />
images is an arraycollection
In the components' code I would like to know which event to listen on everytime images updates props.I tried a setter on props but the setter only gets called once when props is first set. I tried the collection event but I get "Update" events sent on top of 'add' and 'remove' events and I would rather not have to manage those. So is there an event(flex or otherwise) that is fired every time a component property is updated by a bindable property?
I think you want to listen to the collectionChange event on the prop property. This should fire every time an element in your ArrayCollection changes.
Be warned that changing the source of images not fire the collectionChange event, nor will it fire the prop setter.
Related
I am looking for a way to detect when a new a-frames element has been added as a child of a given element(like "child-attached") but doesn't fire until the elements components have been initialized
alternatively, is there an event that is raised after an elements components have all been initialized?
The loaded event will fire when all components initialized. This event doesn't bubble. I would have a component that you attach to the dynamically added entities, and listen to load event. Better yet, set dependencies to wait for the exact component you need.
Related, the componentinitialized event will fire for each initialized component.
I have editable grids which are 2-way binded to my model. What I want is to validate my data when user edits any cell before it get updated in model. I have applied my validation at ItemEditEnd handler, but, I want to apply validation in between itemEditBegin and itemEditEnd events.
any ideas how to achieve this?
For this level of validation I would create a Validator for the type of data you're editing (string, number, etc.) and set the Validator's trigger to the change event of your itemEditor component.
Check out Adobe's example on using validators in an itemEditor for more info.
Update:
You may also want to check out this related question.
"In your event listener, you can
examine the data entered into the item
editor. If the data is incorrect, you
can call the preventDefault() method
to stop Flex from passing the new data
back to the list-based control and
from closing the editor."
What is event bubbling in Flex?
First, event bubbling is not specific to Flex, it's a feature related to AS3 event propagation.
Event propagation means the transference of a single event applying to multiple display objects. Each of those objects receives the event, instead of just the object in which the event originated.
I won't cover all the details of event propagation, google it for more info
(http://www.adobe.com/devnet/actionscript/articles/event_handling_as3_03.html)
Event bubbling means an event dispatched from a display object will bubble up the display list, starting from the object dispatching the event to the stage.
Notice that you can also use the capture phase to listen to an event dispatched by one of a display object's children. See my comment here
Is there not an event that occurs only when there has been some sort of visual change to an object. So for example if it were a video or animated object it would be firing as often as EnterFrame. However, if it were some sort of input control just sitting there doing nothing visually, then the event wouldn't fire until the visual state changed as a result of some sort of user input for example.
I've tried dozen's of events and none of them seem to fire this way.
For visual components about the closest you're going to get is FlexEvent.UPDATE_COMPLETE which will fire after an object has it's commitProperties(), measure() and updateDisplayList() called. If you're subclassing the component, then overriding updateDisplayList() and handling (or throwing you're own event) in there would ensure that you're only getting the event when something visual changes.
For video, you'll want to listen to VideoEvent.PLAYHEAD_UPDATE
At first glance, the Repeater control looks extremely powerful, but now I'm having second thoughts.
Problem at hand:
Adding Event Listeners to the children
Repeater object is bound to and iterates through an ArrayCollection creating new Vbox children for each item. Now for each child, the Repeater object will fire off a "repeat" event, where I'm tempted to add the eventlistener (for mouse events). No problems so far, but, what happens when the ArrayCollection changes, how should I remove the EventListeners for all the old children? Is there an array of children containing my Vbox instances that I'm skipping over in the docs? Are eventlisteners cleaned up nicely when the object they are attached to is destroyed?
-C coder lost in flex/actionscript
I would avoid using Repeaters entirely. From a performance standpoint they are very slow because the items are frequently destroyed and recreated. You are better off using a List-based control and implementing an itemRenderer.
Event listeners by default are strong references, so if you do not remove your event listeners it will prevent the object from being garbage collected. You can use the optional 5th parameter in the addEventListener called "weakReference" and set the value to true to add an event listener that will not prevent GC.
To better deal with events in your itemRender component, you can implement the IDropInListItemRenderer interface. This will give you access to "listData" which has an "owner" property which is the actual List object itself. In your itemRenderer, dispatch a custom Event containing the necessary data through the owner. If you add an event listener to the List control after it's created then you can do the event handling in the component containing the control.
Ok, seems I needed to give the vbox an id, after that I was able to access that id as an array of vboxes. After adding the event handler, I was able to use the event's currentTarget.getRepeaterItem() as a reference to the object in the ArrayCollection.
Cleaning up the event handlers was taken care of by looping over the vbox array and removing the handlers.
Not too worried about performance, as there are few items and they rarely change over the time the program is running, though those items would be different almost every run. Unless it's needlessly destroying and recreating items, it shouldn't be much of an issue.