Thursday, January 22, 2009
ListView SelectedIndexChanged vs ItemSelectionChanged
I stumbled upon the most frustrating C# dilemma to-date.
I was trying to work out a solution to an issue, and -- naturally -- when an item was selected in my list of items, I wanted to do some magic. What would you reach for in this case? The standard SelectedIndexChanged event. That's what we use in Lists, ListBoxes, or even ComboBoxes. That should work in ListViews too... right?
Wrong. ... sometimes.
The event exists, so you can use it, but the "sender" is the actual ListView object, and the EventArgs does not contain any handle to let you know which item was selected/unselected. When a user un-selects an item from the list (with six or seven more still selected), I needed to know which one they disabled so that I could do some more magic. But without keeping a list of previously-selected items around, I couldn't immediately tell which one was freshly un-selected.
ENTER: ItemSelectionChanged.
This is the correct event to be using in these cases. It exists (apparently) only for ListViews. Why the change? I'm not sure. Backward-compatibility, maybe? Who knows!
The thing that makes this most useful is that it has an event manager that is much more defined. This event manager returns not only which item is changing, but it tells you whether it is changing from selected to unselected (or vice-versa) and which index it is in the overall list. It's a very beautiful thing.
So the next time you use a ListView control, keep this little gem in your back pocket.
I was trying to work out a solution to an issue, and -- naturally -- when an item was selected in my list of items, I wanted to do some magic. What would you reach for in this case? The standard SelectedIndexChanged event. That's what we use in Lists, ListBoxes, or even ComboBoxes. That should work in ListViews too... right?
Wrong. ... sometimes.
private void SomeList_SelectedIndexChanged(object sender, EventArgs e)
{
// Tell me which item in your list just changed... you can't.
// You only know that SOMETHING changed. Worse than that... for
// each item that changed, this event fires, but you don't know
// which one it was nor if the selection went from selected
// to unselected or the other way around.
}
The event exists, so you can use it, but the "sender" is the actual ListView object, and the EventArgs does not contain any handle to let you know which item was selected/unselected. When a user un-selects an item from the list (with six or seven more still selected), I needed to know which one they disabled so that I could do some more magic. But without keeping a list of previously-selected items around, I couldn't immediately tell which one was freshly un-selected.
ENTER: ItemSelectionChanged.
This is the correct event to be using in these cases. It exists (apparently) only for ListViews. Why the change? I'm not sure. Backward-compatibility, maybe? Who knows!
The thing that makes this most useful is that it has an event manager that is much more defined. This event manager returns not only which item is changing, but it tells you whether it is changing from selected to unselected (or vice-versa) and which index it is in the overall list. It's a very beautiful thing.
So the next time you use a ListView control, keep this little gem in your back pocket.
private void SomeList_ItemSelectionChanged(object sender,
ListViewItemSelectionChangedEventArgs e)
{
// Note the ListViewItemSelectionChangedEventArgs item.
// It is a HUGE name, but very important.
}
Labels: C-Sharp
Subscribe to Posts [Atom]
Post a Comment