03-20-2011 04:54 AM
Who needs March Madness when you can have Cell Renderer Madness ...
Solved! Go to Solution.
03-20-2011 07:31 AM
Are you deleting the data items out of the data Provider?
You can check out the filtering I do on data and then reset the list which should be a similar idea. Since deleting is basically filtering the data of the list's data provider.
Here is the example code:
03-20-2011 05:04 PM
Yes, I'm deleting data items out of the list's dataprovider. I'm looking over your code example.
BTW can you clarify which function call you mean when you say you reset the list? Do you mean specifically and exclusively the setData method in ListContainer? I notice you scroll to list items as well; I found that scrolling a list will sometimes make previously invisible list items visible again, but not in every case.
In my case for example I have a list with 12 items, the last ~5 of which are not initially visible. I then scroll to the end of the list, select the check boxes for the last 5 items (at this point the first ~5 items are not visible in the list viewport), and delete the last 5 items using the removeItemAt() method of the list control. This causes the list to no longer have more items than will fit in the viewport. This is a case in which the first 4 list items disappear. I had added some hackish code in my handler function that deletes checked list items, to scroll the list to the top and then back to the index of the last deleted item, and it works (i.e. gets the first few items in the list to re-render) as long as I don't delete too many items from the end of the list.
My next hack was to loop through the dataprovider after deleting items, and using the methods of the list control, get the indices of the list items that were not visible with getIsCellVisibleAtIndex(), get the list items' objects using getItemAt(), and just put that object back into the same index with replaceItemAt(), but this did not get the items to render either. This seems perhaps similar to but different from your setData() method, as you replace the entire dataProvider. I'm guessing that replacing the entire dataProvider is the magic sauce here, that forces a brand new set of cell renderers to be instantiated, but it seems kind of brute force. Again it would be great to find a good writeup on cell renderer lifecycle management but for now I'll settle for a hack that works reliably.
03-20-2011 05:59 PM
An update: Completely replacing the list's dataProvider fixes this rendering problem. I'm assuming here that the old dataProvider object that gets supplanted is supposed to lose all references and become eligible for garbage collection - Renaun can you confirm that is the way your code is supposed to work?