Introduction
While talking with one of our customers, he wanted an additional feature in one of our programs to let him drop a number of files onto our application and then modify certain properties of the resulting documents in a list.
Showing these documents in a ListView
can be done easily, but editing of single properties requires a little work (since built-in ListView
only allows plain editing of a ListViewItem
's text). Because I didn't find anything pre-built, I decided to write my own in-place editing for ListView
s, so here it is...
How It Is Done
In fact, in-place editing in a ListView
isn't too much magic, but there are a few places where the plain .NET Framework classes aren't sufficient, so I had to use a little Interop.
First, you have to have a control to perform the actual editing of the SubItem
. Which control you use is (almost) completely up to you. TextBox
, ComboBox
or DateTimePicker
works fine, for example. Since this control is used only when a SubItem
has been clicked, it should be invisible in the beginning.
Then you have to find out which SubItem
has been clicked. This part is quite straightforward, I've added a method GetSubItemAt()
to my ListViewEx
to make things a little easier.
A little twist comes from column reordering. Standard ListView
allows you to rearrange its columns while in report view (AllowColumnReorder
property). Unfortunately, there is no built-in way to find out the current order of your columns, so this is where Interop came in handy:
[DllImport("user32.dll", CharSet=CharSet.Ansi)]
private static extern IntPtr SendMessage(IntPtr hWnd,
int msg, int len, ref int [] order);
private const int LVM_FIRST = 0x1000;
private const int LVM_GETCOLUMNORDERARRAY = (LVM_FIRST + 59);
Using these declarations, you can use the LVM_GETCOLUMNORDERARRAY
message to get the ListView
's current column order.
The next step is to move the editor control in place and to make it visible. Once the actual editing is being performed, the user must be able to accept or reject any changes he makes, so there are a few events that have to be caught while editing.
Usually, a click outside the editor control accepts any changes made, as does the Return key. Pressing ESC while in in-place editing mode converts back to the original SubItem
text.
Because the editor control actually is not part of the ListView
, I also had to look for any action that might change the size or location of the editor control. This was done overriding WndProc
:
protected override void WndProc(ref Message msg)
{
switch (msg.Msg)
{
case WM_VSCROLL:
case WM_HSCROLL:
case WM_SIZE:
EndEditing(false);
break;
case WM_NOTIFY:
NMHDR h = (NMHDR)Marshal.PtrToStructure(msg.LParam, typeof(NMHDR));
if (h.code == HDN_BEGINDRAG ||
h.code == HDN_ITEMCHANGINGA ||
h.code == HDN_ITEMCHANGINGW)
EndEditing(false);
break;
}
base.WndProc(ref msg);
}
Here, scrolling and resizing of the ListView
are monitored as well as changes to the ListView
's column headers. If one of these messages is received, the input focus is transferred back to the ListView
, thus ending in-place editing.
How to Use ListViewEx for in-place Editing
There are two ways to perform in-place editing with ListViewEx
. First, you can use the new SubItemClicked
event together with GetSubItemBounds()
to position your editor control by yourself, or you can use StartEditing()
, which performs all required calculations and control positioning by itself.
So, usually you would start by adding a ListViewEx
and at least one control used as a cell editor to your Form
. Don't forget to make your cell editor control invisible! Then wire up an event handler for SubItemClicked
and actually start editing:
private void listViewEx1_SubItemClicked(object sender,
ListViewEx.SubItemClickEventArgs e)
{
listViewEx1.StartEditing(comboBox1, e.Item, e.SubItem);
}
That's it!
I've included a small sample application to show you how to use ListViewEx
with several different cell editors. Feel free to use the control or the source to your heart's desire and have fun!
Additional Features
Your comments gave me some hints on missing features, so meanwhile I've added an additional property DoubleClickActivation
so that you can decide if the ListViewEx
should enter editing mode when you click on a subitem or if a double click is required.
Another point was adding two new events (SubItemBeginEditing
and SubItemEndEditing
) to give the caller the possibility to control what's displayed in the editing control and what gets put back into the ListViewSubItem
.
Now you're able to add a password field as a cell editor and transfer the plain password to and from the edit control without having it shown in the listview
. Take a look at the sample project to see how it's done.
History
- 09.04.2004
- 19.04.2004
- Update to account for editor control and
ListViewEx
not sharing the same parent (thanks Eric-Paul) - Fixed code has been uploaded
- 19.10.2004
- Reviewed the whole project
- Fixed a few bugs
- Added new features (
DoubleClickActivation
, new events, higher level of control over the editing process,...