I have my own custom component. This component extends from a basic container. I want to be able to access the itemRenderer instances that are being visualized. I know that the component mx:list has an internal getter that provides an array of Arrays containing the itemRenderer instances that render each data provider item. I want the same thing. Any idea how of how to do that?
To be more specific: I am setting the selected property of my dataProvider items to true or false. From the updateDisplayList funcion of my ItemRenderer I check for changes of the property and correct the border color of the selected ones. Unfortunately I have to force the updateDisplayList function. I already did this once on a ItemRenderer from a list. Only with the list it was practical because by making my own list I was able to get the list of items being rendered and therefore visualized (cannot be many). It was no overhead to go trough the rendered Items and updateDisplayList. But in this case I can have 100 items. Imagine checking and changing styles on so many items. Thanks
The Flex architects intentionally made this difficult to do, because they are properly encapsulating the component. In short, to even try to do this is a violation of good OOP principles.
That said, about 90% of the things you are probably trying to do can be done by manipulating the data item, and the remaining 10% can be done by using a ClassFactory for your itemRenderer that sets a custom property on your itemRenderer to a callback where you can look at the data available to the containing context and provide back a value based on that.
If you elaborate a bit more on your end goal, I can give you more specifics.
Edit in light of clarification:
You need to make your data object class dispatch an event when it changes (one way is to make it bindable, or just make the selected property bindable). Then, in your renderer, listen for the change event and take the appropriate action.
A second way to handle this would just be to refresh() the collection, storing the selectedItem first (if you care about that) and resetting it once the refresh has finished.
I believe you can access the itemRenderer instances through getChildAt method. Flex 3's container overrides "getChildAt", "numChildren", given that some children are logical children, while some are decorative children such as background, border and scrollbars.
Keep in mind that itemRenderer may not right away become available upon dataProvider assignment, as they may be created during the next component lifecycle. Check with the underlying container's documentation and find out which event to be listened when the renderers are surely created, so you can reliably access them.
Related
I have a UI object that, of course, should always be kept in front of all other objects. To do that, I decided to destroy and add it again each frame, like this:
removeChild(UI_Indicator)
addChild(UI_Indicator)
But nevertheless, objects that are created in it’s area still come on top of it. How is this even possible? I also tried the common
UI_Indicator.parent.setChildIndex(UI_Indicator,UI_Indicator.parent.numChildren - 1)
But it doesn’t work too. Any suggestions?
You are not destroying anything with removeChild(), you just stop displaying it. removeChild() isn't even necessary here. addChild() happily takes a DisplayObject that is already a child of the DisplayObjectContainer you called it on and re-adds the child again (to the top)
Instead of doing this readdChild()ing every frame, place your
allways-on-top DisplayObject on the display list once, then create
a DisplayObjectContainer, say a Sprite for example and add it
behind your indicator. Now add all your other DisplayObjects to
that container. This has the disadvantage of requiring you to add
everything to the container. The functionality breaks as soon as you
accidentally addChild() the regular way. This thought process
leads to the second solution below.
In your subclass of DisplayObjectContainer that includes the
indicator, override the methods that interact with the display list
(add/remove children, etc.) All those that could cause something to
get on top of your indicator. This puts you in full control of
what's going on when something is added to this container. You can
either incorporate solution 1 for simplicity's sake: delegate all
method calls to the inner container Sprite or, if you don't like
to have an internal container, do it without it and make sure that
no other child than your indicator is ever assigned the top most
index. You'd create an additional method to add the always-on-top child, like addTopChild() for example.
I'm using a custom item renderer in my datagrid, and need to make a button visible or invisible based on if there has been a negative value on any of the values in the renderer. So I'd like to set a flag to false when the first renderer is set off, turn it to true if there's any negative values, and at the end check for the value of the flag. I know I can dispatch a dataChange event for every time the data is changed in the renderer instances, but I was wondering if there is anyway I can know when all of them are done?
Thanks!
There is no such event.
Like any other Flex component, a renderer will dispatch a CREATION_COMPLETE after it's been created. ItemRenderers are generally recycled (the same object gets assigned new data to render), thus listening for CREATION_COMPLETE is not sufficient, unless you disable the recycling.
For a Spark List component, you can disable recycling by setting useVirtualLayout=false on the layout class. I'm not sure if the Spark DataGrid class support this or not. The MX DataGrid may have some other way to do this.
Disabling the recycling, however, can have performance implications. I think your idea w/the DATA_CHANGE event is the best solution:
determine the initial state of the data (ie: are there any negative values)
in the renderer, use the DATA_CHANGE event (or just override the setter for the renderer's data property) to know when the data has changed
When the data changes, dispatch a custom event class that will bubble. This event has a property that tells you if the value is negative or not.
Since your custom event from the renderers will bubble up to the grid, you can add one listener on the grid to handle changes from all the renderers.
You should have a look into RendererExistenceEvents. You should be able to tell when they are all created based on how many items you have in your list or at least how many should be in view at once.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/events/RendererExistenceEvent.html
I have created a custom dijit widget which contains a grid and some buttons.
What is the right way to destroy it? override uninitialize, destroy, destroyRecursive? which method and in which order?
Thanks.
Generally uninitialize is the best place to do this, since it is an extension point called within the destroy function before other teardown occurs.
That said, depending on how you are adding your child widgets, you may not actually have to do anything. For instance, if you are defining your child widgets within a template, widgets declared within a template automatically get added to an array which is iterated through in destroy.
If you wanted to be sure, for testing you could connect to the destroy methods of your child widgets to log a message when they get called.
Since flex memory management is poor, objects once instantiated dont die very easily (even when they go out of scope), one would need to check on various properties of components. I am using one such thing to know if the screen (which is a display object) is in current view. For this I am turning on a boolean property (currently visible), and I am setting it true on show event of the display object.
What I need to know is, which event (something opposite of show, e.g left?) could be used when the screen is replaced by another display object?
Something like focusIn and focusOut from dotnet.
Or if there is some property which could directly tell me if the display object is currently in view (hasFocus doesnt seem to be giving me expected results).
Thanks.
You can Use PropertyChageEvent check the documentation and base of the newValue and kind property you can do some action :
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/events/PropertyChangeEvent.html
hope this help
Name of the event is: removedFromStage.
I have two Spark Lists with custom Item Renderers. I'm working on an application that enables users to drag these Item Renderers from one List to the other. When one of these IRs is dropped in a new position or in another List, I'm updating the dataproviders: I remove the object from one list's dataprovider and add it to the other's dataprovider. This is working ok.
The problem is that sometimes the IR is cached and it doesn't show the correct information, based on its data.
How can I force the Lists to never cache IRs, so that every time I modify the dataprovider all Item Renders re-create all IRs. Performance won't be an issue since I have few items on each list.
A few things..
1) ItemRenderers should always be cached [and reused]. This is one of the benefits of using a Flex list in the first place. I suspect your itemRenderer is implemented inorrectly as to not change when it's data changes. If you share some code for this it would be helpful. But, basically, your itemRenderer should listen to the dataChange event and when the data changes you should update the component's visual display with new data.
2) In Flex 3, I'd have sworn that dragging an item from one list to another automatically updated the relevant dataProviders. Are you sure you need to write manual code to make those changes? You will, though, need code to update your backend as relevant.
Flextras has some good points, but to answer your specific question, you can set useVirtualLayout to false on Spark Lists. This will ensure there is a renderer for every item in your list and thus avoiding the recycling issues. You should really only do this when you have a relatively short list of items though, otherwise you will have performance issues, which as Flextras noted, is the reason Flex recycles renderers.
I put a reset method in my set data to assure renderer variables are reinitialized
override public function set data(object:Object):void
{
if (object == null)
{
return;
}
reset(); // reset locals to their base. ie. x=0, y=0, counter=0
// set up renderer using data
}