
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 ListViews, 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,...