Friday, December 21, 2007

WPF Progress Bars

Note: I've posted an updated, even easier to use version of this code here:

WPF Progress Bars Revisited

Implementing a progress bar display for long-running tasks is a commonly occurring task. WPF has a simple ProgressBar control which works as you would expect. It has a floating point Value property that is used to display progress within a range (set using the Minimum and Maximum properties). Here is some XAML to implement a progress dialog:
<Window x:Class="MyNamespace.ProgressDialog"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Progress Dialog" Width="300" SizeToContent="Height">
<Grid>
<StackPanel Margin="10">
<ProgressBar Name="Progress" Width="200" Height="20" Minimum="0" Maximum="1" Margin="10" />
<TextBlock Name="StatusText" Margin="10" Height="50"/>
<StackPanel Orientation="Horizontal" FlowDirection="RightToLeft">
<Button Name="CancelButton">Cancel</Button>
</StackPanel>
</StackPanel>
</Grid>
</Window>

The progress bar is set to take progress values from 0 to 1, and has a TextBlock for displaying a status message.

It might seem like we are finished, but it is only part of what you need for a functional progress dialog. In trying to use the dialog, you quickly run into a problem - how to avoid blocking the UI thread while your operation proceeds. In Windows Forms, a common cheat was to periodically call Application.DoEvents() to allow the UI to update. While you can do something similar in WPF, it is ugly and best avoided.

Instead, you should do your work asynchronously in a separate thread. Given that, the next question becomes how to update the UI from your second thread, as WPF UI operations are not thread-safe, and you will get an exception if you try to interact with a control outside of the thread in which it was created. The solution? Use the Dispatcher. The Dispatcher basically lets you queue up function calls on the UI thread from your background thread.

To manage this communication, we will first create an interface for interacting with a progress dialog:
public interface IProgressContext
{
void UpdateProgress(double progress);
void UpdateStatus(string status);
void Finish();
bool Canceled { get; }
}

The UpdateProgress() method allows us to set the current progress value, UpdateStatus() allows us to display a text status message, Finish() lets us signal that our operation has completed, and the Canceled property allows us to check if the user has canceled the operation.

Now, the code-behind for the dialog:
public partial class ProgressDialog : Window, IProgressContext
{
private bool canceled = false;

public bool Canceled
{
get { return canceled; }
}

public ProgressDialog()
{
InitializeComponent();

CancelButton.Click += new RoutedEventHandler(CancelButton_Click);
}

void CancelButton_Click(object sender, RoutedEventArgs e)
{
canceled = true;
CancelButton.IsEnabled = false;
}

public void UpdateProgress(double progress)
{
Dispatcher.BeginInvoke(DispatcherPriority.Background,
(SendOrPostCallback)delegate { Progress.SetValue(ProgressBar.ValueProperty, progress); }, null);
}

public void UpdateStatus(string status)
{
Dispatcher.BeginInvoke(DispatcherPriority.Background,
(SendOrPostCallback)delegate { StatusText.SetValue(TextBlock.TextProperty, status); }, null);
}

public void Finish()
{
Dispatcher.BeginInvoke(DispatcherPriority.Background,
(SendOrPostCallback)delegate { Close(); }, null);
}
}

As you can see, we are basically just implementing the IProgressContext interface. We use the dispatcher to send along our progress updates to the UI thread. To use the dialog, launch a background thread to do your work, passing it a progress dialog as IProgressContext. Your work loop will look something like this:
for (int i = 0; i < 100; i++)
{
if (myProgressContext.Canceled)
break;

myProgressContext.UpdateProgress((double)i / 100.0);
myProgressContext.UpdateStatus("Doing Step " + i);
}

myProgressContext.Finish();

You can obviously get more fancy with your dialog - this is just a simple implementation to get started with.

Wednesday, December 12, 2007

Drag and Drop in WPF

Drag and Drop in WPF is, I think, more complex than it should be. I've had to implement it a few times now, so I recently put together a simple helper class that simplifies things.

The full class code follows at the end of the post, but first I will give a few examples of using it. If you have an object that you want to be draggable, just create a DragDropHander object for it:
DragDropHandler dragDrop = new DragDropHandler(myControl, new System.Windows.DataObject(myDragData));
Where "myControl" is the WPF control the use will drag from, and "myDragData" is the object you wish to receive on the other end of the drag and drop. To receive the drop, make sure the control you want to drop to has AllowDrop set, and add a drop handler in your control initialization:
MyControl.Drop += new DragEventHandler(MyControl_Drop);

Implement the handler like this:
void MyControl_Drop(object sender, DragEventArgs e)
{
MyDataType myData = (MyDataType )e.Data.GetData(typeof(MyDataType).ToString());

// Do something with the dropped object
}
If you want to drag an object outside of your application, you need to create the appropriate DataObject. A common case is a filename. To create a drag handler that drags a filename, do:
DragDropHandler dragDrop = new DragDropHandler(myControl, new System.Windows.DataObject(DataFormats.FileDrop, new string[] { myPath }));
You can obviously get much more complicated with drag and drop - handling drag enter/over/leave events and using adorners to visually display drag data, for example. This should get you started, though, and probably is sufficient for most needs.

Here is the full DragDropHandler class implementation:
using System;
using System.Windows.Data;
using System.Windows;
using System.Windows.Input;

namespace MyCoolNamespace
{
public class DragDropHandler
{
private FrameworkElement dragElement = null;
private bool dragging = false;
private bool inDragDrop = false;
private Point dragStart;
private DataObject dataObject = null;

public DragDropHandler(FrameworkElement dragElement, DataObject dataObject)
{
this.dragElement = dragElement;
this.dataObject = dataObject;

dragElement.MouseLeftButtonDown += new MouseButtonEventHandler(dragElement_MouseLeftButtonDown);
dragElement.MouseMove += new MouseEventHandler(dragElement_MouseMove);
}

void dragElement_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
if (!dragElement.IsMouseCaptured)
{
dragging = true;
dragStart = e.GetPosition(dragElement);
}
}

void dragElement_MouseMove(object sender, MouseEventArgs e)
{
if (dragging)
{
Point currentPos = e.GetPosition(dragElement);

if ((Math.Abs(currentPos.X - dragStart.X) > 5) || (Math.Abs(currentPos.Y - dragStart.Y) > 5))
{
dragElement.CaptureMouse();

inDragDrop = true;
DragDropEffects de = DragDrop.DoDragDrop(dragElement, dataObject, DragDropEffects.Move);
inDragDrop = false;
dragging = false;
dragElement.ReleaseMouseCapture();
}
}
}
}
}

WPF ListView - Getting the Clicked Item

I recently had the need to figure out which item in a WPF ListView was under the mouse when it was clicked. The solution wasn't completely straightforward, so I thought I'd post it here.

First, obviously you need to register a mouse button event hander in your control initialization. In this case, I'm using a double-click event:
MyListView.MouseDoubleClick += new MouseButtonEventHandler(MyListView_MouseDoubleClick);
and then implement the event handler like such:
void MyListView_MouseDoubleClick(object sender, MouseButtonEventArgs e)
{
DependencyObject dep = (DependencyObject)e.OriginalSource;

while ((dep != null) && !(dep is ListViewItem))
{
dep = VisualTreeHelper.GetParent(dep);
}

if (dep == null)
return;

MyDataItemType item = (MyDataItemType)MyListView.ItemContainerGenerator.ItemFromContainer(dep);

// Do something with the item...
}
What we are doing is walking up the visual tree starting at the element the generated the mouse event. We stop when we find a ListViewItem, which we can then use to get the corresponding data item. If all you want is the index of the item, use IndexFromContainer() instead.

Monday, December 3, 2007

C# Xml List Serialization Behavior

Xml serialization in C# is, for the most part, simple and transparent. Public properties of your objects are automatically written to and read from a corresponding Xml representation. Usually this happens exactly as you would expect, but there are a few gotchas in serialization of lists.

Take this example object:

public class XmlTest
{
private List<int> integerList = new List<int> { 1, 2, 3 };

public List<int> IntegerList
{
get { return integerList; }
set { integerList = value; }
}
}


We have a single property which is a list of integer values. If we create an object and serialize it:

XmlTest xmlTest = new XmlTest();
TextWriter writer = new StreamWriter("test.xml");
XmlSerializer serializer = new XmlSerializer(typeof(XmlTest));
serializer.Serialize(writer, xmlTest);
writer.Close();


we get the following Xml, just like we would expect:

<?xml version="1.0" encoding="utf-8"?>
<XmlTest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<IntegerList>
<int>1</int>
<int>2</int>
<int>3</int>
</IntegerList>
</XmlTest>


But when we deserialize the generated Xml like so:

FileStream fs = new FileStream("test.xml", FileMode.Open);
XmlReader reader = new XmlTextReader(fs);
xmlTest = (XmlTest)serializer.Deserialize(reader);
fs.Close();


we get a surprise. The integer list in the deserialized object has 6 items rather than three. The list ends up being "1, 2, 3, 1, 2, 3". Why is this? It has to do with the details of how lists are deserialized. If you put a breakpoint in the "set" of the IntegerList property, you will find that it never gets called during deserialization. Instead, it seems that the .NET deserializer uses "get" to access the property, and then calls "Add()" to deserialize the list items. Because we initialize the list to "1, 2, 3", those items are already there before adding the items from the Xml.

I don't know that I am prepared to call this behavior "wrong", but it certainly was unexpected for me. Ideally, serializing and then deserializing an object would result in the exact same data. In this case, not so much.

A better behavior, I think, would be for the deserialzer to creat a new list, populate it from the Xml, and then call my property's "set" method to hook it into my object. This also would allow you to put business logic in your property and have it survive serialization. At the very least, it would probably make sense to clear the list before adding items during deserialization.