Getting the true SelectionIndex when using the FilterBar in a ListPicker

I've been using the ListPicker.SelectionIndex property to tell which record was selected. I added a FilterBar to be clever, and to my horror the SelectionIndex ends up always being 1, when the user searches for a unique item.  I have a situation where the text in the Elements list *usually* has no duplicates but there is a possibility that it may.  So finding the list item based on the text is suspect.  Is there any way to find the true index #?

--

I added a FilterBar to be clever, and to my horror the SelectionIndex ends up always being 1

I just tested it and it returns the correct SelectionIndex for me regardless of if there are duplicates or not.

Could you cobble together an example that shows this behavior?

It is possible that there is a bug in the AI software and if so I need to submit a bug report.

ListPickerFilter.aia

--

if you have a list with 5 items A,B,C,D,E and you filter for let's say B, you will get the selection index 1 in the end... this is the selection index of the filtered list, which is not the selection index of the complete list...

--

that's exactly what I'm experiencing.  I had been using SelectionIndex to figure out exactly which option the user selected.  I'm kindof at a loss to figure out how to accomplish that now, except to use the Selection text, which I'm uneasy about.  I like IDs.

--

Maybe instead of SelectionIndex, you could use Selection to find out what has been picked??

-- 

Maybe instead of SelectionIndex, you could use Selection to find out what has been picked??

as a workaound this could be done as soon as there are no duplicates in the list...

is this a bug or a fefature?

in my opinion it would be better to get the selection index of the complete list back

--

I still don't see what the issue is.

It worked for me.

Try my example aia project above.

--

click onto the listpicker, then filter for b and pick b, the selection index is 1

other example: click onto the listpicker, don't filter and pick a, the selection index is 1

other example: click onto the listpicker, then filter for d and pick d, the selection index is 1

the selection index doesn't say something about the index of the complete list, and: did the user filter the list of not? so which element did he pick? a, b or d? you don't know that...

--

 a, b or d? you don't know that...

you don't know that only by looking at the selection index

of course you can take a look at the selection...

That's how it should really be.

If your complete list is a,b,c,d,e (c has index of 3) and user filters to c, r you saying that the index should still be 3??

--

If your complete list is a,b,c,d,e (c has index of 3) and user filters to c, r you saying that the index should still be 3??

yes, because currently you can't use the selection index, actually you have to ignore it if the filter bar is enabled...

--

I don't think that sounds right.

I think the question is how does the user intend to use the selection index.

I think the proper way is to use Selection() where it gives the actual value and then comparison can be done to see what has been picked from ListPicker.

Even if list has dup items, then same conditional check would would work for both.

--

I think the question is how does the user intend to use the selection index.

so how can the user use the selection index currently if the filter bar is enabled? 

--

As mentioned before, they should use Selection block.

--

I agree with Taifun, in my opinion it would make more sense to get the index of the complete list returned. It would be more useable.

--

Let's assume the picker has sorting feature.  If the picker is sorted, at runtime by user,  what should happen to selection index?  If original list is a b c d and user sorts in descending,  what should be selection index of d?

--

the selection index should always be the selection index of the original list, in this case 4

--

You can use index in list with the Selection property to return the index of the first match even if there are duplicates.

--

I suppose if the list is sorted, then the index would have changed.

If so, so what?

--
unless the list is linked by index to another list in which case you should probably be sorting an index to the list rather than the list itself.

--

It looks like there are really two questions here.

1. What is SelectionIndex used for?

2. What's wrong with using Selection (perhaps combined with [index in list]) to figure out what was selected

For #1, the way I see it, if you can't rely on SelectionIndex (at least if you have the FilterBar enabled), then why have it? Do we all just want to agree that it should not be used in conjunction with the FilterBar?  Or to Taifun's point can it be made to work with the original list.  As Scott mentioned immediately above, I use the Elements list in conjunction with larger lists so the indexes are synchronized.

Separately, #2 is definitely feasible.  However there remains the possibility of duplicate items in the Elements list.  Granted, in all scenarios that I can think of, it would be due to a bit of sloppy programming, but what's AI for if not to appeal to the amateur?  

I do like the suggestion of retaining the original index when sorting.  I think it would be even more useful if it could have a "hidden" column with reference IDs.  (key-pairs). That would mean that you could really get rid of SelectionIndex since you would have the ability to create a unique index on your own.

--
For index that's just how android works.  If someone knows how to manipulate and update sdk code to change the standard behavior of android, that would be great and please let us know how. 

--

 if you can't rely on SelectionIndex (at least if you have the FilterBar enabled), then why have it? Do we all just want to agree that it should not be used in conjunction with the FilterBar?  

yes, currently we have to say: 

the Selection Index should not be used together with the FilterBar

this is confusing and should be fixed in my opinion...

the selection index should always be the selection index of the original list

--

Please let's take this to open-source forum so that someone can do sdk update and show us how that works. 

--