Is there an easy way to associate an event with a ListViewItem?

Question

I have a WinForms ListView, obviously containing ListViewItems. I'd like to be able to attach a click event to each item, instead of to the entire ListView (and then trying to figure out what item was clicked). The reason for this is that I need to perform a different action based on which item was selected. The ListViewItem class seems to be very limited in this regard. Is there any way to do what I want, or am I forced to use the ListView.Click event?

Answer 1

It may make sense to subclass ListViewItem and use virtual dispatch to select the appropriate behavior based on the selected ListViewItem in the appropriate ListView event.

E.g. (uncompiled)

public abstract class MyItems : ListViewItem
{
    public abstract DoOperation();
}

public class MyItemA : MyItems
{
    public override DoOperation()
    { /* whatever a */ }
}

public class MyItemB : MyItems
{
    public override DoOperation()
    { /* whatever b */ }
}

// in ListView event
MyItems item = (MyItems)this.SelectedItem;
item.DoOperation();

As others have mentioned, it may also make sense to use the appropriate Tag property. Which technique you go for really depends on what your action is (and therefore where it belongs, architecturally). I assumed the subclass made more sense because you're looking for a click on a listview item, and that (to me) seems more likely to be presentation-layer b/c you're overriding some standard control behavior (which would normally just select an item) as opposed to doing something in response to behavior.

Answer 2

You might however have luck sticking a reference to a delegate or other handler in the tag field (assuming there is a tag property of a ListViewItem). You would still have to determine which ListViewItem is clicked, but you could then go straight to the tag instead of another decision structure.

Answer 3

You want to create a new class (or classes if there are various types), which inherits from ListViewItem, then populate your ListView with these objects (as long as they inherit from listview (even several levels of inheritence) The ListView control will take them).

Then add a click method to your custom class(es) and on the ItemClick event of your listView, just call the click method of the clicked item. (some casting may be needed)

Answer 4

I would still use the ListView Click event. A trick I've used in these situations is to use the Tag property of a ListViewItem. It's great for storing per item data and you can put anything in it.

Answer 5

Actually there is no way to use a ListViewItem. You have to use the ListView itself. By using the 'SelectedItems' property of the ListView you can access the selected ListViewItems.

One option is to override the ListViewItem class an implement the specific stuff in there. Then you can cast the selected item to the overridden one and perform the action.

Answer 6

I really don't understand the reason to do so instead of just using the regular ListView Click event, but if I were to do like you suggest I would assign an EventHandler delegate to the Tag property of each ListViewItem, then in the ListView Click event handler I would check if the ListViewItem.Tag <> null, and if so call the delegate.

Answer 7

In most use cases, a ListViewItem is a representation in the UI of some object, and what you're trying to do is execute a method of the object that the ListViewItem represents when the user clicks on it. For the sake of simplicity and maintainability, you want as few things to sit between the user's mouse-click and the actual method being executed.

You can store the object in the ListViewItem's Tag property and then reference it in the Click event handler, but that results in code that's got some inherent weak points:

private void MyListView_Click(object sender, EventArgs e)
{
   ListView l = (ListView)sender;
   if (l.SelectedItem != null)
   {
      MyClass obj = l.SelectedItem.Tag as MyClass;
      if (obj != null)
      {
         obj.Method();
      }
   }
}

That's a lot of casting and null-reference checking. And the really weak thing about this code is that if it turns out that Tag is null, or contains something other than a MyClass object, you don't really know where to look to find out where the problem is occurring.

Contrast it with code like this:

private void MyListView_Click(object sender, EventArgs e)
{
   MyClass.ListViewClicked(sender as ListView);
}

When you're maintaining this code, you don't know how that ListViewClicked method is implemented, but at least you know where to look for it - in MyClass. And when you do, you'll see something like this:

public static void ListViewClicked(ListView listView)
{
   if (listView.SelectedItem == null)
   {
      return;
   }
   if (ListViewItemLookup.ContainsKey(listView.SelectedItem))
   {
      ListViewItemLookup[listView.SelectedItem].Execute();
   }
}

Well, that's interesting. Following the thread, how does that dictionary get populated? You find that in another method in MyClass:

private static Dictionary<ListViewItem, MyClass> ListViewItemLookup = 
   new Dictionary<ListViewItem, MyClass>();

public ListViewItem GetListViewItem()
{
   ListViewItem item = new ListViewItem();
   item.Text = SomeProperty;
   // population of other ListViewItem columns goes here
   ListViewItemLookup.Add(item, this);
   return item;
}

(Reasonable people can disagree about whether or not it's appropriate for a class to be so closely tied to a specific form of its representation in the UI - there are those who would isolate these methods and this dictionary in a helper class instead of in MyClass itself, and depending on how hairy the rest of the problem is I might do it too.)

This approach solves a number of problems: it gives you a simple way of handling the ListView's Click event properly, which is what you asked for. But it also isolates the not-always-trivial process of creating the ListViewItem in the first place. It reduces the amount of code you'll have to move around if you refactor your form and move the ListView to another form. And it reduces the number of things that your form class needs to know about, which is generally a good thing.

Also, it's testable. Generally, the only way to test code in a UI event handler is through the UI. This approach lets you isolate all of the logic surrounding this part of the UI in something that you can unit test; the only thing you can't write a unit test for is a single line of code in the form.

I should point out that the other approach people have been suggesting - subclassing ListViewItem - is perfectly fine too. You put the logic I put in the GetListViewItem method in the class's constructor, make the MyClass instance a private property of the class, and expose a Click method that calls the method of MyClass. Pretty much the only reason I don't like it is that it still leaves you with a fair amount of code in your form that you can't really unit test:

ListView l = (ListView)sender;
if (l.SelectedItem != null)
{
    MyClassListViewItem item = l.SelectedItem as MyClassListViewItem;
    if (item != null)
    {
       item.MyClass.Method();
    }
}