0

I have an ArrayCollection that is the dataProvider for a spark.components.List, which has allowMultipleSelection="true". There is a "Remove Selected Items" button which initiates the removal of all the selected items from the ArrayCollection upon being clicked.

I currently use the following method:

myList.selectedIndices.sort(ascendingSort);

// remove items, counting backwards
for (var i:uint = myList.selectedIndices.length; i > 0; i--) {
  myArrayCollection.removeItemAt(myList.selectedIndices[i-1]);
}

where ascendingSort does what you expect ;). It works fine, and I know that it will always work.

However, I did take note that if I neglected the sort altogether, to my surprise the removal still worked. The reason for this turned out to be that, when the removeItemAt is called, the selectedIndices are correspondingly updated.

So my question is: Can one rely upon a removeItemAt call updating the values in the selectedIndices? or might that turn out to be different between runtimes and/or Flex SDK versions?

Obviously, if it is reliable then leaving out the sort would be a significant improvement.

merv
  • 67,214
  • 13
  • 180
  • 245

2 Answers2

1

Can one rely upon a removeItemAt call updating the values in the selectedIndices?

Apparently in your use case, yes.

or might that turn out to be different between runtimes and/or Flex SDK versions?

It may very well change at some future point, or may have changed before. I know that in my experience with list based classes, sometimes modifying the dataProvider may cause the list to go back into the "no selection" state. Removing a single selectedItem on a list that does not allow multiple selection is a good example of that.

Usually, in the apps I've worked on, I'm not removing items from a list based on the user's selection in a list; instead they are usually removed (or filtered) out based on some criteria in the actual object. And that criteria usually is a Boolean value that relates to a checkbox shown in a DataGrid column.

JeffryHouser
  • 39,401
  • 4
  • 38
  • 59
  • Thanks for the reply. I'm more interested in any experience you may have had across SDK's and runtimes particularly in regard to the implementation of the method I'm interested in, but even other data binding related methods would be worth knowing of. I guess more fundamentally I'm asking how reliable is the data binding between the properties in a List and the underlying dataProvider. Can you cite any particular instances of implementations that existed in Flex 3, for example, that have changed in Flex 3.6 or 4 or 4.5? – merv Dec 05 '11 at 20:03
  • @merv what is a "data binding related method"? For all intents and purposes, there is no relation to a dataProvider and the properties on a list via binding. Maybe this answer on data binding will help: http://stackoverflow.com/questions/8157901/what-does-the-do/8159057#8159057 . There are plenty of examples of things that changed in versions of the SDK; although I don't know of anything off hand that relates to data binding. – JeffryHouser Dec 05 '11 at 21:28
  • 1
    I apologize for being vague. I'm trying to reference the fact that changes to an underlying dataProvider propagate through to the List component via the CollectionChange event. The particular examples I am trying to solicit are ones which pertain to the implementation of this type of propagation. A very specific example would be whether or not in a prior SDK, updating of selectedIndices required a `refresh()` to be called. Anyway, I ended up just comparing the relevant sections the ListCollectionView.as and ArrayList.as across SDKs, and the code seems to be mostly unchanged since 3.0. Thx. – merv Dec 06 '11 at 19:10
0
var indexes:Vector.<Object> = list.selectedItems;

while(indexes.length > 0 )
{
    var item:* = indexes.pop();
    var remindex:int = list.dataProvider.getItemIndex(item);

    if (remindex != -1)
    {
        list.dataProvider.removeItemAt(remindex);
    }
}
Sergey Glotov
  • 20,200
  • 11
  • 84
  • 98
Max Volos
  • 56
  • 2
  • 1
    I'm rather skeptical that using the `getItemIndex` method would be any improvement over my code (sorting included). Replacing sorting indices with searching for each item's index individually sounds like going from an **O(n log n)** to **O(n²)** algorithm, but admittedly that depends on the internal implementation of the `getItemIndex`. You need to back this up with benchmarks. Besides, my question was whether I can drop the sorting altogether, which would be pushing into **O(n)** performance! :D – merv May 08 '12 at 06:02