Sure, it's always an option (albeit a cumbersome one) to store all the changes in the client code until the user hits OK or Cancel. I just wanted to know whether it is possible to set a "restore point" and later roll back all the changes up to that point. The database is single-user, so there won't be any read/write conflicts.

The dialog doesn't just show some variables. It lists (complex) objects from the database and should allow adding/deleting/editing them. When he adds a new object he might decide to edit it before leaving the dialog, so I need to be able to store its properties somewhere. Of course I could hold the references to the new objects in my code, but I thought the most elegant way would be to store them in the DB immediately and access them in a unified way. Of course I still need the option to roll back all the changes when the user hits Cancel.

Hi, I am trying to implement a dialog for updating some data in a DB. The OK button should actually save the data to the DB, while the Cancel button should discard the changes. The problem is, I need to be able to read the changed but not yet committed data within the dialog. I have read much information about transactions, isolation levels etc. and if I understand it correctly, the only way to achieve this is to wrap all the changes in a single transaction and use the READUNCOMMITED isolation level for it. Then in the OK button handler I'd just commit the transaction and in the Cancel button handler I'd call rollback. However, since I am using the SQLite.NET library, I am only able to use READCOMMITTED or SERIALIZABLE levels. What's more, in some other piece of software I have which uses MS Access database and solves exactly the same problem the transaction is started with the READCOMMITED isolation level and everything works as intended. That really puzzles me. :doh: Do you have any suggestions/advice for this kind of problem?

Thanks for the proposed semi-solution. I put together different pieces and came up with this solution which seems to do what I want :) First, I leave the MultiSelect property set to false and set FullRowSelect to true. Then I use this code:

public class CustomListView : ListView
{
public CustomListView()
{
InitializeComponent();
}

bool fakeMouseUp = false;
bool mouseDownOnItem = false;

protected override void OnMouseDown( MouseEventArgs e )
{
	// if we're not on an item or subitem, we will get OnMouseUp immediately
	mouseDownOnItem = HitTest( e.Location ).Item != null;

	Debug.WriteLine( "OnMouseDown" );

	base.OnMouseDown( e );
}

protected override void OnMouseUp( MouseEventArgs e )
{
	if( mouseDownOnItem || fakeMouseUp )
	{
		Debug.WriteLine( "OnMouseUp" );

		mouseDownOnItem = false;
		fakeMouseUp = false;

		base.OnMouseUp( e );
	}
}

protected override void WndProc( ref Message m )
{
	if( !mouseDownOnItem && m.Msg == 0x0202 /\*WM\_LBUTTONUP\*/ )
	{
		// send a fake MouseUp event
		fakeMouseUp = true;
		Point point = new Point( ((int) m.LParam) & 0x0000FFFF, (int) m.LParam >> 16 );
		OnMouseUp( new MouseEventArgs( MouseButtons.Left, 1, point.X, point.Y, 0 ) );
	}

	base.WndProc( ref m );
}

}

But I always have a feeling of wasted time when I need to do such workarounds for weird .NET behaviour. Why on Earth do I get a MouseUp event when the mouse button was not physically released? :confused:

Yes, that's true, unfortunately I need to properly handle all clicks in the control, not just those on a ListViewItem. It even doesn't work on a ListViewSubItem.

I noticed a weird behaviour in ListView. When its MultiSelect property is set to true and I press a mouse button while the cursor is inside the control, I get a MouseDown event. Then I release the button and get a MouseUp event, just as I would expect. However, when I set the MultiSelect property to false and press a mouse button, I suddenly get the MouseUp event immediately after the MouseDown one. When I then actually release the button, no MouseUp fires. Is this intentional? How can I then properly determine when the mouse button was actually released?