Vincent Sibal's Blog

New and updated test tools for WPF: TestApi v0.3 and WPF Control Verifier

Vincent Sibal - MSFT — Tue, 04 Aug 2009 15:09:00 GMT

TestApi v0.3

The WPF test team has recently released a new version of TestApi! This version includes libraries for fault injection, combinatorial varitation generation, new application control APIs, and updated tests and documentation. I think all the new libraries are really cool, especially the fault injection libraries. Learn more about it here.

WPF Control Verifier v0.1

In addition to TestApi, the test team has also developed a tool to verify the behavior of WPF controls. WPF Control Verifier is a tool that verifies the correctness of WPF Controls. This tool is geared towards WPF Control developers with the goal of providing a set of verifications that all controls can run and consume. Version 0.1 includes one category for verification – default style verification. These tests verify that your control can be styled such that its dependency properties are inheriting or template binding correctly. Future versions will include additional categories of verification. You can download the tool here. This is our first beta and we will be updating it based on your feedback. We have a planned set of features for future iterations but this will evolve based on your suggestions. Please send your feedback to wpfcvt@microsoft.com.

The Control Local Values Bug Solution and new WPF 4.0 related APIs

Vincent Sibal - MSFT — Thu, 21 May 2009 17:57:00 GMT

Intro

Previously I did a post on the “Control Local Values bug” and how a subtle bug can be introduced when setting dependency properties of controls to local values. In WPF 4.0 (dev10), a mechanism was added to the property engine to solve this problem. Here are the new APIs in dev10:

public class DependencyObject

{

// Sets the value of a dependency property without changing its value source.

public void SetCurrentValue(DependencyProperty dp, object value);
}

public struct ValueSource

{

public bool IsCurrent { get; }

}

Basically, when using DependencyObject.SetCurrentValue instead of DependencyObject.SetValue you set its effective value but its ValueSource remains the same. This is very similar to coercion.

Sample Test App

To make it more clear, I wrote a sample test app that shows the BaseValueSource and ValueSource properties when changing a DependencyProperty (DP) via SetCurrentValue. I created a custom control with a DP, TitleProperty, where I track its values. In addition, I setup several scenarios where the TitleProperty is initially set by a particular BaseValueSource. I’ll go through one scenario here.

I setup the custom control where the TitleProperty is set from a Style with a binding.

<Setter Property="Title"

Value="{Binding RelativeSource={RelativeSource Self},

Path=WorkingTag,

StringFormat='Set via Style w/ Binding: {0}'}" />

<Setter.Value>

<Button Content="{TemplateBinding Title}"

Background="{TemplateBinding Background}" />

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

<local:CustomControl x:Name="CustomControl_Style_Binding"

Style="{StaticResource StyleBindingCustomControlStyle}"/>

</GroupBox>

Initially it will look like this:

Notice the BaseValueSource is ‘Style’, IsExpression is ‘True’, and IsCurrent is ‘False’ as expected. After pressing the “Set Current Value” button the values will update accordingly:

Now the local value has updated to a new string that I set and IsCurrent has updated to ‘True’. Also notice that BaseValueSource and IsExpression have not changed which is also expected. If you press “Clear Local Value” the values will update back to their initial values. Now to bring back the original issue with the control local values bug, if you were to set or clear the local value any previous BaseValueSource would be overwritten and any expression lost. I have created other scenarios in the sample with different BaseValueSource behavior so you can understand how setting the current value behaves in those scenarios. Please be sure to check it out below.

Usage Recommendation

For a control developer, the general recommendation is to always use DependencyObject.SetCurrentValue over DependencyObject.SetValue in Control code. You’ll notice that our stock controls in the 4.0 framework have all been updated to use this API instead of setting the properties with local values.

Here is the sample app which works with VS 2010 beta 1.

VS 2010 and .NET Framework 4.0 Beta1 are out now!

Vincent Sibal - MSFT — Thu, 21 May 2009 17:54:00 GMT

As many of you probably already know, dev10 beta1 is available for public download. Some of the additions to Beta1 on the WPF Controls side include:

· MultiTouch

· EasingFunctions for animations

· DataGrid, Calendar, DatePicker, and VisualStateManager in PresentationFramework.dll

· New APIs to support the control local values bug

· And tons of bug fixes on the new controls as well as existing control and element services areas

I’ll be going over some of these new features in more depth so stay tuned!

WPF Model-View-ViewModel (MVVM) Toolkit 0.1

Vincent Sibal - MSFT — Sat, 02 May 2009 17:59:00 GMT

The WPF team has just released an MVVM Toolkit which contains an overview and walkthrough of the MVVM pattern, a full Messenger sample app using MVVM, as well as a Visual Studio template for MVVM. The template creates a WPF application with folders for Views, ViewModels, Models, and Commands. What I really like about it is the DelegateCommand class which is similar to RelayCommand. One addition to this version of the Command implementation is the ability to manually control when OnCanExecuteChanged is called or let the CommandManager control it. The common scenario will be the latter, but allowing the option for the former will allow greater control over application performance due to the many calls to OnCanExecuteChanged. In the future, the plan is to get this as well as other MVVM concepts into the WPF framework. You can learn more about it here and download it here. Check it out and we would love to hear your feedback.

WPF TestApi v0.2 has released!

Vincent Sibal - MSFT — Fri, 24 Apr 2009 20:39:00 GMT

The WPF test team is hard at work to provide value through a simple and componetized library of public test APIs. The WPF TestApi library has just released a v0.2 which includes new visual verification features, command line parsing features, an auomated application controller, and new unit test samples.

Ivo has a great post about the visual verification APIs and usage that you can view here. Please try it out and let us know your feedback!

5 More Random Gotchas with the WPF DataGrid

Vincent Sibal - MSFT — Tue, 14 Apr 2009 16:21:00 GMT

1. DataGridColumn.SortDirection does not actually sort the column.

DataGridColumn.SortDirection is used to queue the visual arrow in the DataGridColumnHeader to point up, down, or to not show. To actually sort the columns other than clicking on the DataGridColumnHeader, you can set the DataGrid.Items.SortDescriptions programmatically.

Here is an example of an ICommand used to trigger grouping of a particular column in the DataGrid. In addition to grouping it, I also sort it on the same column name that I grouped it with. Note that this code will programmatically sort the column but will not update the sorting arrow since I did not update SortDirection.

public ICommand GroupColumn

{

get

{

if (_groupColumn == null)

{

_groupColumn = new RelayCommand<object>(

(param) =>

{

// the delegate is passed in the column header

// name which matches the Binding on the column

string header = param as string;

// SearchResults is the ItemsSource that DataGrid

// is bound to. Below I programmatically group and

// sort the collection based on the header name

SearchResults.GroupDescriptions.Add(

new PropertyGroupDescription(header));

SearchResults.SortDescriptions.Add(

new SortDescription(header, ListSortDirection.Ascending));

});

}

return _groupColumn;
}

}

2. DataGridColumns cannot be styled as they are not FrameworkElements.

DataGridColumn derives from DependencyObject, not FrameworkElement, and therefore cannot be styled like many of the other elements on DataGrid. You can think of a DataGridColumn as data storage for what each cell’s content will be template with and a couple other properties like the width of each cell and how it is sorted. They are not meant to be visual elements like DataGridCell or DataGridRow.

3. While editing a row, the row is committed by pressing Enter, pressing tab on the last cell of the row, losing focus, clicking the column header to sort the column, programmatically calling DataGrid.CommitEdit, updating DataGrid.CurrentCell to a cell outside the current row, or updating DataGrid.CurrentItem.

The actions described above are the default actions to commit a row. One action that deserves a little more clarification is the commit on losing focus. Each DataGridCell listens for changes to its IsKeyboardFocusWithin property and when it changes it updates the CurrentCell accordingly (which causes the row to commit).

4. Disable commit behavior through the DataGrid.RowEditEnding event

In the previous gotcha I explain all the ways that a row can be committed. If you want to customize that behavior, the best way to do it is through DataGrid.RowEditEnding. This event is fired at the start of any and all row commits and you have the ability to cancel the commit behavior in this event through DataGridRowEditEndingEventArgs.Cancel. See more about editing behavior here.

5. Customize focus behavior after a row commit through the DataGrid.RowEditEnding event

While there isn’t a DataGrid.RowEditEnded at this time (March 2009 Release), you can use the Dispatcher trick to get custom behavior after a row commit has occurred. In DataGrid.RowEditEnding, you can specify a Dispatcher.BeginInvoke so that the code in the delegate is executed after the row commit has completed. Here is some example code which sets focus to the second cell of the next row and puts it in edit mode but only when I press tab on the last cell of the row before the NewItemPlaceholder.

private void OnRowEditEnding(object sender, DataGridRowEditEndingEventArgs e)

{

if (e.EditAction == DataGridEditAction.Commit)

{

// custom commit action:

// tab specific behavior for editing workflow.

// moves to the next row and opens the second cell for edit

// if the next row is the NewItemPlaceholder

if (_isTabPressed &&

e.Row.Item == dataGrid.Items[dataGrid.Items.Count - 2])

{

// set the new cell to be the last row and the second column

int colIndex = 1;

var rowToSelect = dataGrid.Items[dataGrid.Items.Count - 1];

var colToSelect = dataGrid.Columns[colIndex];

int rowIndex = dataGrid.Items.IndexOf(rowToSelect);

// select the new cell

dataGrid.SelectedCells.Clear();

dataGrid.SelectedCells.Add(

new DataGridCellInfo(rowToSelect, colToSelect));

this.Dispatcher.BeginInvoke(new DispatcherOperationCallback((param) =>

{

// get the new cell, set focus, then open for edit

var cell = Helper.GetCell(dataGrid, rowIndex, colIndex);

cell.Focus();

dataGrid.BeginEdit();

return null;

}), DispatcherPriority.Background, new object[] { null });

}

See more WPF DataGrid gotchas.

Launching a custom Dialog to edit items in a DataGrid (with MVVM)

Vincent Sibal - MSFT — Fri, 10 Apr 2009 16:53:00 GMT

Launching a custom dialog for editing on the DataGrid is another somewhat common request that I see from the discussion list. I thought I would provide a sample but at the same time implement it with the MVVM pattern. The requirement that I will use on the sample is that the editing mechanism can only come from the editing dialog that I provide.

I decided that the way to launch the custom dialog will be through double-clicking on the row. To get that behavior, I will use the attached behavior pattern on DataGridRow. The behavior is defined like so:

public class DataGridRowBehavior

{

public static DependencyProperty OnDoubleClickProperty = DependencyProperty.RegisterAttached(

"OnDoubleClick",

typeof(ICommand),

typeof(DataGridRowBehavior),

new UIPropertyMetadata(DataGridRowBehavior.OnDoubleClick));

public static void SetOnDoubleClick(DependencyObject target, ICommand value)

{

target.SetValue(DataGridRowBehavior.OnDoubleClickProperty, value);

}

private static void OnDoubleClick(DependencyObject target, DependencyPropertyChangedEventArgs e)

{

var element = target as DataGridRow;

if ((e.NewValue != null) && (e.OldValue == null))

{

element.PreviewMouseDoubleClick += OnPreviewMouseDoubleClick;

}

else if ((e.NewValue == null) && (e.OldValue != null))

{

element.PreviewMouseDoubleClick -= OnPreviewMouseDoubleClick;

}

private static void OnPreviewMouseDoubleClick(object sender, MouseButtonEventArgs e)

{

UIElement element = (UIElement)sender;

ICommand command = (ICommand)element.GetValue(DataGridRowBehavior.OnDoubleClickProperty);

command.Execute(e);

}

The behavior is then used on the DataGridRow like this:

<Setter Property="local:DataGridRowBehavior.OnDoubleClick"

Value="{Binding ShowEditItemDialogCommand}" />

</Style>

What’s happening is the OnDoubleClick attached property listens for a property change on itself. I define an ICommand, ShowEditItemDialogCommand, on OnDoubleClick which then hooks up the actual event handler, PreviewMouseDoubleClick, on the target element. In that event handler, OnPreviewMouseDoubleClick, I retrieve the value of OnDoubleClick which is my ICommand and execute it. So now we have the behavior to launch a dialog through a double-click action. The next thing is to define the ICommand ShowEditItemDialogCommand.

I have defined a DataGridRow ViewModel which hosts the actual item data as well as any properties that will drive the view (the DataGridRow). It also will host any commands on a DataGridRow which for our purposes will be the ShowEditItemDialogCommand. My commands are also implemented using the RelayCommand mechanism that is discussed on this MSDN article. So here is the basic implementation:

public class ItemViewModel : ViewModelBase

{

private ICommand _editItemCommand;

public ICommand ShowEditItemDialogCommand

{

get

{

if (_editItemCommand == null)

{

_editItemCommand = new RelayCommand(

() =>

{

// pass the item to the dialog

var dlg = new EditItemDialog(Item);

if (dlg.ShowDialog() == true)

{

// retrieve the updated item from the dialog

Item = dlg.Result.Item;

}

});

}

return _editItemCommand;
}

}

So when DataGridRowBehavior.OnPreviewMouseDoubleClick executes the command, my ShowEditItemDialogCommand will initiate the launch of the new dialog. The dialog that is being launched is basically a new Window which is considered a View. From a MVVM purist perspective this does not belong in a ViewModel. To handle this you can use the mediator design pattern to host the communication between the ViewModel and the View. There are a couple ways to implement this pattern which include implementing it as an observer pattern or using a specialized communication mechanism through interfaces and references. I’ve chosen the latter and in the sample code you can see I’ve named it EditDialogDirector to be clear on its behavior. I won’t show all the details here.

Now, I said earlier that I set a requirement that editing can only come from the dialog that I provide. While there are a lot of ways to customize the editing behavior, I decided to keep it really simple and set DataGrid.IsReadOnly to true. It does mean that I will lose the default editing capabilities that DataGrid provides, but I won’t have to keep state on DataGrid begin and commit edits. There are some other details that I’m leaving out but the full sample code below will give you a good idea of how everything is pieced together. Also, there is a lot of great reference material and samples on MVVM to further enhance your knowledge on the subject.

http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx

http://karlshifflett.wordpress.com/mvvm/

http://www.codeproject.com/KB/WPF/InternationalizedWizard.aspx

Download the full sample here.

5 Random Gotchas with the WPF DataGrid

Vincent Sibal - MSFT — Tue, 07 Apr 2009 16:54:00 GMT

Since the release of the WPF DataGrid there have been several common patterns of questions that developers were asking on the discussion list. I thought that I would capture some of that here so it would be easy to find. I'll also try to keep it as short as possible and refer to other links for more information. These gotchas are in no particular order.

1. DataGridColumns are not part of the visual tree.

Since a DataGridColumn has a Binding DP it is easy to think that bindings to other DataGridColumn DPs will work just the same but they don't. Below is an example showing a DataGridCheckBoxColumn setting the Binding DP and CanUserSort through data binding. While Binding will bind correctly, CanUserSort will not.

<dg:DataGridCheckBoxColumn Header="Selection"

Binding="{Binding IsSelected}"

CanUserSort="{Binding CanSort}"/>

Note that the reason Binding does work is because the internal code dynamically sets the binding of DataGridColumn.Binding to the DataGridCell.Content. It does not do so for the other DataGridColumn DPs.

Workaround => Check out Jaime’s post on how to get the DataGridColumns to use the same DataContext as the DataGrid.

2. DataGridColumn.Binding will automatically coerce the binding to BindingMode.TwoWay and UpdateSourceTrigger.Explicit

No matter how you declare the binding for DataGridColumn.Binding, internally it will coerce the BindingMode to TwoWay and UpdateSourceTrigger to Explicit (even if you set them explicitly yourself). This is because the DataGrid manages the binding operations itself for editing functionality. Now, you might run into an issue when you have a read-only property with a TwoWay binding mode. If you set DataGridColumn.IsReadOnly to true, then the BindingMode will not be coerced to TwoWay.

3. You manage the bindings when using a DataGridTemplateColumn.

The DataGrid internal code does not coerce the bindings set on DataGridTemplateColumn because DataGridTemplateColumn doesn’t even have a Binding DP. Since you are setting the bindings up yourself, you have to tell it when to commit. One common way to do this is to setup a OneWay binding on the UIElement in the CellTemplate and a TwoWay binding on the CellEditingTemplate. See this previous post for example code (under “Template Columns”). The example code uses an UpdateSourceTrigger of PropertyChanged. If that does not suite your needs for committing the data, you can mimic what the DataGrid internal code does and update the source yourself. Set the UpdateSourceTrigger to Explicit and listen to the DataGrid.CellEditEnding event. You can then update the source explicitly in that event.

4. Use DataGridColumn.ElementStyle and DataGridColumn.EditingElementStyle to set properties on a cell’s Content.

Each stock DataGridColumn type produces a specific type of Control as the content for each DataGridCell in the column. See this previous post for more info on that. It seems that the first instinct to set properties on the cell’s content is to set them through the DataGridCell Style when they should instead be set on DataGridColumn.ElementStyle and/or DataGridColumn.EditingElementStyle. ElementStyle is the Style applied to the non-editing element. EditingElementStyle is for the editing element.

In a previous gotcha, I mention that DataGridColumns are not part of the visual tree. With that said, you can still create bindings that map to the same DataContext as DataGridColumn.Binding on DPs from a Style set on DataGridColumn.ElementStyle and DataGridColumn.EditingElementStyle. That is because these styles are applied dynamically to the cell’s content which has the correct DataContext. Below I am setting a DataGridTextBoxColumn’s ElementStyle. Notice that I have a binding setup on Background with a “MyBrush” property path. I am assuming that property is coming from the DataContext of the DataGridCell (which is the same DataContext of the DataGridRow).

<dg:DataGridTextColumn Header="First Name"

Binding="{Binding Path=FirstName}">

<dg:DataGridTextColumn.ElementStyle>

</Style>

</dg:DataGridTextColumn.ElementStyle>

</dg:DataGridTextColumn>

5. Data source items should implement IEditableObject to get transactional editing functionality.

If you are not familiar with IEditableObject, see this MSDN article which has a good explanation and code sample. The DataGrid has baked in functionality for transactional editing via the IEditableObject interface. When you begin editing a cell, the DataGrid gets into cell editing mode as well as row editing mode. What this means is that you can cancel/commit cells as well as cancel/commit rows. For example, I edit cell 0 and press tab to the next cell. Cell 0 is committed when pressing tab. I start typing in cell 1 and realize I want to cancel the operation. I press ‘Esc’ which reverts cell 1. I now realize I want to cancel the whole operation so I press ‘Esc’ again and now cell 0 is reverted back to its original value.

See more WPF DataGrid gotchas.

The Control Local Values Bug!

Vincent Sibal - MSFT — Tue, 24 Mar 2009 23:06:00 GMT

Intro

WPF dependency properties are properties that are registered through the WPF property system. By registering with the property system, the property will be provided a set of services such as data binding, styling, change notifications, animation, expressions, invalidation, and coercion. What I will be discussing here is dynamic value resolution and the issue of setting local values in controls.

Background

A dependency property’s value is dependent on multiple providers where there is a level of precedence for each provider. The BaseValueSource enum captures these providers (with the first being the lowest precedence and last being the highest)

· Unknown

· Default

· Inherited

· ThemeStyle

· ThemeStyleTrigger

· Style

· TemplateTrigger

· StyleTrigger

· ImplicitStyleReference

· ParentTemplate

· PatentTemplateTrigger

· Local

In addition to these base value sources, the dependency property can also come from an expression, animation, or coercion (which the internal WPF code represents them as ModifiedValues). Note that ModifiedValues are mutually exclusive from BaseValueSource. For example you can have a value that is set locally and coerced at the same time.

So how does this relate to the control local values bug?

As a control author, dependency properties are the general mechanism to communicate the state and behavior of the control. They will be used in data binding scenarios, visual representation, interaction, etc. This means that you will possibly and most likely be setting values on your dependency properties internally as state changes about your control. So as you are setting new values to a dependency property that you own, you may not realize that you are introducing a very subtle bug relating to dynamic value resolution precedence. I’ll use an example to clarify.

The DatePicker control from WPFToolkit has a DP called IsDropDownOpen. It is used by the DatePicker control to update when the calendar popup opens and closes. It listens for a change event and sets the Popup.IsOpen accordingly.

private static void OnIsDropDownOpenChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

{

DatePicker dp = d as DatePicker;

Debug.Assert(dp != null);

bool newValue = (bool)e.NewValue;

if (dp._popUp != null && dp._popUp.IsOpen != newValue)

{

dp._popUp.IsOpen = newValue;

}

The Popup also listens for when it opens and closes and makes sure IsDropDownOpen is toggled to the correct state.

private void PopUp_Opened(object sender, EventArgs e)

{

if (!this.IsDropDownOpen)

{

this.IsDropDownOpen = true;

}

…

}

Notice the bug? The bug lies in PopUp_Opened when setting IsDropDownOpen to a local value. This really appears harmless and you probably won’t actually see the bug in action until you hand it over to the app developer who will actually set different value providers on your control DPs. The problem is that setting a DP locally as an internal operation in your control will trump any and all value providers set on that DP (as local is the highest precedence). That means that the app developer who uses your control and decides to put some fancy styles, binding, triggers, and all that goodness will find that it will stop working for some reason and not immediately know what caused it.

To further describe how this can occur, here is an example using that same DatePicker (note that this has already been fixed in later version of the toolkit).

<Window.Resources>

</Style>

</Window.Resources>

<Grid>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

<toolkit:DatePicker Grid.Row="1"

Name="datePicker"

Style="{StaticResource DatePickerStyle}" />

</Grid>

I’ve setup a style on the DatePicker where I’ve bound a CheckBox.IsChecked DP to the DatePicker.IsDropDownOpen DP. If you click on the CheckBox, the popup opens as expected. If you take a look at the BaseValueSource on IsDropDownOpen it will read Style. However, as soon as you close the popup, the binding does not work anymore which is expected since a local value is set on IsDropDownOpen.

Summary

To make it really short and sweet, setting dependency properties to local values in internal operations of a control can lead to the dreaded control local values bug. I’m sure you’re next question is, how can this be prevented? Well, I will be doing a follow-up post on what has been added in dev10 to easily prevent this bug so stay tuned!

UPDATE: Check out the follow up post here.

WPFToolkit March 2009 Release and new WPF Themes!

Vincent Sibal - MSFT — Fri, 20 Mar 2009 15:36:00 GMT

An updated version of the WPFToolkit has been released today. This includes some high pri bug fixes which are briefly described in the downloads tab. As a reminder, if you have any questions or find any issues please use the Discussion list and the Issue Tracker. Enjoy!

Also, a new set of WPF Themes has also been released in the WPF Futures section. This is a collection of 9 themes that are also found in the Silverlight Toolkit.

Exploring MVVM: Grouping with the DataGrid

Vincent Sibal - MSFT — Wed, 21 Jan 2009 16:46:00 GMT

Model-View-ViewModel (MVVM) is one of those really interesting design patterns that are used in WPF. It provides a separation between the UI and business logic and uses data binding techniques to connect them together. Karl Shifflett has some great material on MVVM that you can read about here.

Anyway, I thought I’d dig into some of the details starting with grouping items in a DataGrid. I was originally building a test app for modeling animations of DependencyProperties and ended up using a DataGrid to show the DPs, their current values, and animation properties. I found that I really needed all the sorting, grouping, and filtering capabilities to analyze test values so I wanted to update the DataGrid and use the MVVM pattern (as much as possible).

Grouping by column

To group by column I decided to use a context menu on the column header. In the context menu, the MenuItems are hooked up to commands on my ViewModel like so:

<MenuItem Name="mi_group"

Header="Group by this column"

Command="{Binding RelativeSource={RelativeSource FindAncestor,

AncestorType={x:Type local:Window1}},

Path=DataContext.GroupColumn}"

CommandParameter="{Binding RelativeSource={RelativeSource Self},

Path=DataContext}"/>

<MenuItem Name="mi_clearGroups"

Header="Clear grouping"

Command="{Binding RelativeSource={RelativeSource FindAncestor,

AncestorType={x:Type local:Window1}},

Path=DataContext.UngroupColumns}" />

</ContextMenu>

My ViewModel is the DataContext for the main window and implements these commands with a MVVM commanding style introduced by Josh Smith called RelayCommand. You can find it in his Crack.NET solution as well as other MVVM samples here and here. Here is the code for grouping:

public ICommand GroupColumn

{

get

{

if (_groupColumn == null)

{

_groupColumn = new RelayCommand<object>(

(param) =>

{

string header = param as string;

DPCollection.GroupDescriptions.Add(new PropertyGroupDescription("TargetProperty." + header));

DPCollection.SortDescriptions.Add(new SortDescription("TargetProperty.Name", ListSortDirection.Ascending));

});

}

return _groupColumn;
}

}

DPCollection is the CollectionView that I set on the DataGrid.ItemsSource. So triggering this command will set a group on a particular property and sort by its name. The important part is really how the command is being implemented in the ViewModel and through a delegate style of commanding such as RelayCommand.

Expanding and Collapsing Groups

I really wanted to follow a pattern similar to Josh’s and Bea’s TreeView examples but unfortunately the grouping implementation is not so extensible. When you setup GroupDescriptions, the ItemContainerGenerator of the ItemsControl will create these GroupItem visuals and will set the DataContext of each GroupItem to a CollectionViewGroupInternal object. This CollectionViewGroupInternal object holds information about the items in the group, its name, count, etc. The xaml for my GroupStyle without custom expanding or collapsing looks like this:

<GroupStyle.HeaderTemplate>

</StackPanel>

</DataTemplate>

</GroupStyle.HeaderTemplate>

<GroupStyle.ContainerStyle>

<Setter.Value>

<Expander.Header>

</DockPanel>

</Expander.Header>

</Expander>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

</GroupStyle.ContainerStyle>

</GroupStyle>

Notice the properties “Name” and “ItemCount” which are properties on the CollectionViewGroup which is a base class of CollectionViewGroupInternal. Also notice the Expander.IsExpanded property. I needed some way to bind some kind of ViewModel property to Expander.IsExpanded.

The problem is that CollectionViewGroupInternal is Internal as you might have suspected and I was unsuccessful in applying a class adaptor to the base class object without affecting the grouping functionality. So I decided to put an IsExpanded property directly on each of the items instead. While this is more of a hack as IsExpanded means nothing to the item by itself, it is relatively cheaper and really may be a more realistic solution than re-implementing grouping on a custom CollectionView. Here is the updated xaml:

<GroupStyle.HeaderTemplate>

</StackPanel>

</DataTemplate>

</GroupStyle.HeaderTemplate>

<GroupStyle.ContainerStyle>

<Setter.Value>

<Expander.Header>

</DockPanel>

</Expander.Header>

</Expander>

</ControlTemplate>

</Setter.Value>

</Setter>

</Style>

</GroupStyle.ContainerStyle>

</GroupStyle>

I have made the assumption that it will check the first item in the group but that is ok as I only care able expanding or collapsing all groups. When I clear grouping or group a different column, all IsExpanded properties are reset so there are no side effects on the next group.

Finally, the command for expanding looks like this:

public ICommand ExpandAllGroups

{

get

{

if (_expandAllGroups == null)

_expandAllGroups = new RelayCommand(

() =>

{

if (DPCollection.Groups != null)

{

foreach (object groupItem in DPCollection.Groups)

{

var group = groupItem as CollectionViewGroup;

group.Items[0] as ElementViewModel).IsExpanded = true;

}
}

});

return _expandAllGroups;

}

I have attached a full sample here, which is a stripped down version of the test app I was building.

WPF DataGrid Sample: Locking input to the row being edited

Vincent Sibal - MSFT — Thu, 18 Dec 2008 19:45:00 GMT

Scenario

By default the WPF DataGrid will commit a row when focus is lost on the row, the ‘Enter’ key is pressed, tabbing to the next row, or programmatically calling commit on the row. Let’s say I want to control how the user commits a row edit by locking input to just that row being edited and having a filtered set of input or a single input of my choosing that will commit that row.

Implementation

There are no configuration APIs on the DataGrid that allow you to tell it what input will commit a row, but there are events that allow you to cancel editing operations as you so choose. So we can work around that. Another thing we will have to do is keep track of the editing state of the DataGrid. With this extra flag, we can also use it to disable other rows while the current row is being edited.

You can subclass DataGrid and add functionality that may be more generalized but for this sample I’m just going to use a UserControl. Here is the flag that I will use which is a DP so it can be used in the DataGridRow style.

public partial class CustomDataGrid : UserControl

{

public bool IsEditingRow

{

get { return (bool)GetValue(EditingRowProperty); }

set { SetValue(EditingRowProperty, value); }

}

public static readonly DependencyProperty EditingRowProperty =

DependencyProperty.Register(

"IsEditingRow",

typeof(bool),

typeof(CustomDataGrid),

new FrameworkPropertyMetadata(false, null, null));

}

This flag is going to be used such that anytime a row is being edited, other rows will be disabled and you can only commit through an input that I choose. To disable the rows we can add something like this in the row’s style:

<Style.Triggers>

<MultiDataTrigger.Conditions>

</MultiDataTrigger.Conditions>

</MultiDataTrigger>

</Style.Triggers>

</Style>

For naming purposes I probably should have called it IsInEditMode to differentiate but please indulge me for now. So anyway, if the DataGrid is editing a row and the particular row is not in edit mode it will be disabled.

Now, for the logic, two important events for this scenario are:

· DataGrid.BeginningEdit

· DataGrid.RowEditEnding

BeginninigEdit will be used to set the IsEditingRow flag as well as cancel a BeginEdit operation when trying to open a different row for edit while still editing the current row.

private void DataGrid_Standard_BeginningEdit(object sender, DataGridBeginningEditEventArgs e)

{

if (!IsEditingRow)

{
// set edit mode state

IsEditingRow = true;

_currentEditingRow = e.Row;
}

else if (e.Row != _currentEditingRow)

{

// cancel all new edits for different rows

e.Cancel = true;

}

RowEditEnding will be used to cancel a commit if IsEditingRow is true. It also resets when the row edit is cancelled.

private void DataGrid_Standard_RowEditEnding(object sender, DataGridRowEditEndingEventArgs e)

{

if (e.EditAction == DataGridEditAction.Cancel)

{

// cancelling the entire row will reset the state

IsEditingRow = false;

}

else if (e.EditAction == DataGridEditAction.Commit)

{

e.Cancel = IsEditingRow;

}

So for this workaround, it is really based on how you want to manipulate IsEditingRow. For this sample, I want to commit a row only when the ‘Enter’ key is pressed. I can do that by listening to the PreviewKeyDown event and setting IsEditingRow to false for the ‘Enter’ key.

private void DataGrid_Standard_PreviewKeyDown(object sender, KeyEventArgs e)

{

DataGridRow row = GetRow(DataGrid_Standard, DataGrid_Standard.Items.IndexOf(DataGrid_Standard.CurrentItem));

if (row.IsEditing && e.Key == Key.Enter)

{

// only 'Enter' key on an editing row will allow a commit to occur

IsEditingRow = false;

}

That’s basically it. If you try out the sample you will see that when you open a row for edit, the rest of the rows will be disabled and the only way to commit is through the ‘Enter’ key.

Let’s say ‘Enter’ to commit is not the functionality you want. Instead you want to commit using a specific button. In that case you can listen to the click event or setup a command and set IsEditingRow accordingly based on your specific conditions.

You can download the full sample here.

WPF DataGrid – Dynamically updating DataGridComboBoxColumn

Vincent Sibal - MSFT — Wed, 17 Dec 2008 19:07:00 GMT

The Scenario

I want to do a master detail like scenario where the selection in one ComboBox cell will update the list of items in the next ComboBox cell and so on.

Setting up the DataSource and ViewModel

I will use the Northwind database for this example and will use the first column to select a Category within the Categories table.

The second column will have a ComboBox to select all the Products within the selected Category.

And the third column will have a ComboBox to select all the orders that were placed on the selected Product.

The ViewModel that I will use on each DataGrid item will have the properties:

· CurrentCategory

· CurrentProduct

· CurrentOrder

· ProductsInCategory

· OrdersFromProduct

Each time CurrentCategory is updated, ProductsInCategory will be updated as well to create the new list of products. When CurrentProduct is updated, OrdersFromProduct will be updated in a similar fashion. So for example, CurrentCategory will look like this:

public int CurrentCategory

{

get { return _currentCategory; }

set

{

_currentCategory = value;

ProductsInCategory = DBAccess.GetProductsInCategory(_currentCategory).Tables["Products"].DefaultView;

OnPropertyChanged("CurrentCategory");

}

GetProductsInCategory() does a query on the database passing in the category id. I will not go over the database querying implementation here.

Hooking up to the UI

For the first DataGridComboBoxColumn, the ComboBox.ItemsSource will bind to the Categories DataTable through a StaticResource. The binding on the column will be set to the CurrentCategory.

<dg:DataGridComboBoxColumn Header="Current Category"

SelectedValueBinding="{Binding Path=CurrentCategory}"

SelectedValuePath="CategoryID"

DisplayMemberPath="CategoryName"

ItemsSource="{Binding Source={StaticResource categoriesDataProvider}}">

</dg:DataGridComboBoxColumn>

The other DataGridComboBoxColumns will have to take a slightly different approach. Let’s say we do something like this:

<dg:DataGridComboBoxColumn Header="Current Product"

SelectedValueBinding="{Binding Path=CurrentProduct}"

SelectedValuePath="ProductID"

DisplayMemberPath="ProductName"

ItemsSource="{Binding Path=ProductsInCategory}">

</dg:DataGridComboBoxColumn>

It does seem more intuitive to take this approach however DataGridColumns are not actually part of the visual tree and only the Binding DPs will actually be set on generated cell elements to inherit DataGrid’s DataContext. That means that the binding for ItemsSource will fail as it won’t be able to find path, ProductsInCategory, that it is current set.

Aside: Jaime wrote this nice post on how to set the DataContext for the columns to DataGrid’s DataContext, but I’m going to show an implementation here with just the default implementation.

So what we want is for the ItemsSource to bind to the DataContext of the row on the DataGrid. We can do that by setting the binding on the actual generated element of the column through ElementStyle and EditingElementStyle.

<!—now itemssource will find the correct DataContext-->

<dg:DataGridComboBoxColumn Header="Current Product"

SelectedValueBinding="{Binding Path=CurrentProduct}"

SelectedValuePath="ProductID"

DisplayMemberPath="ProductName">

<dg:DataGridComboBoxColumn.ElementStyle>

</Style>

</dg:DataGridComboBoxColumn.ElementStyle>

<dg:DataGridComboBoxColumn.EditingElementStyle>

</Style>

</dg:DataGridComboBoxColumn.EditingElementStyle>

</dg:DataGridComboBoxColumn>

This works because internally when the cell is being generated, the Content of the cell will have its layout updated which will make it part of the visual tree and it will have access to the correct DataContext. Now the ItemsSource for the ComboBox will dynamically update each time CurrentCategory is changed. The DataGridComboBoxColumn for the CurrentOrder is similar to CurrentProduct so I will not show that here.

You can download the sample here.

WPF TestApi and DataGrid Sample

Vincent Sibal - MSFT — Wed, 10 Dec 2008 19:33:00 GMT

Our WPF Test team has just released a library of tools that can be leveraged to test WPF applications. What's really cool is that these are utilities that we use internally and now we can push them out to external customers for feedback and usage. The library currently lives here on codeplex, http://www.codeplex.com/TestApi. There are a couple more blog posts where you can get more information about it.

http://blogs.msdn.com/llobo/archive/2008/12/08/wpf-test-helper-library.aspx

http://blogs.msdn.com/wpfsdk/archive/2008/12/09/testapi-released.aspx

The download contains some samples but I thought I would show a sample with one of the DataGrid applications instead.

I made some small modifications to the SampleTestApp to get it working with one of my DataGrid samples. In this sample, I am doing a visual verification test to check that the rows and cells update to the correct visual state when in edit mode. I am using the in-proc, out of thread strategy which is similar to the strategy used in the visual verification in the SampleTestApp.

To get the tests to work with the DataGridSample application, I needed to add automation id’s to some of the elements. In particular, the Window and the DataGrid:

<Window x:Class="DataGridSample.DataGridBasicSample"

AutomationProperties.AutomationId="DataGridBasicSample">

…

<dg:DataGrid x:Name="DataGrid_Standard"

AutomationProperties.AutomationId="DataGrid_Standard">

</dg:DataGrid>

…

</Window>

These IDs will be queried by my test in order to find the correct AutomationElements. And here is what the test will basically look like (left out logging and some error checking to make it more concise):

// retrieve the necessary AutomationElements

AutomationElement window = AutomationUtilities.FindElementsById(AutomationElement.RootElement, "DataGridBasicSample")[0];

AutomationElement dataGrid = AutomationUtilities.FindElementsById(window, "DataGrid_Standard")[0];

GridPattern grid = dataGrid.GetCurrentPattern(GridPattern.Pattern) as GridPattern;

AutomationElement cell = grid.GetItem(0, 0);

// do action for making cell editable

AutomationHelpers.MoveToAndDoubleClick(cell);

// Capture the actual pixels from the bounds of the screen rectangle

Snapshot actual = Snapshot.FromRectangle(AutomationHelpers.GetElementSize(dataGrid));

// Load the reference/master data from a previously saved file

Snapshot master = Snapshot.FromFile(Path.Combine(TestContext.TestDeploymentDir, "Master_EditTest1.png"));

if (CompareImages(actual, master) == VerificationResult.Fail)

{

Assert.Fail("Initial State test failed. Actual should look like Master image. Refer to logged images under:" + TestContext.TestLogsDir);

}

Download the full sample here. We would love to hear your feedback.

WPF DataGrid Design-time Walkthrough

Vincent Sibal - MSFT — Fri, 07 Nov 2008 18:29:00 GMT

The DataGrid walkthrough on windowsclient.net/wpf and the Tips & Tricks section on codeplex talk briefly about the Design-time support for DataGrid. I thought I’d expand on that just a little more so you get a good idea of what you have available.

Installation

So to get it to work you need to install the toolkit using the WPFToolkit.msi (download from here). This will put the dlls under your “C:\Program Files\WPF Toolkit\<version number>\” directory as well as set a reg key in Visual Studio to recognize the controls in the toolbox. In your application, you will need to reference the wpftoolkit.dll from this install directory location to get the design-time support to work.

Walkthrough

Ok, I’ll start from the very beginning.

0. Install and set a reference to wpftoolkit.dll

1. Open the Toolbox. You should see a group with DataGrid, DatePicker, and Calendar.

a. If you don’t, you can add them by right-clicking in the Toolbox, selecting “Choose Toolbox Items”, tab to the WPF Components tab, then selecting DataGrid, DatePicker, and Calendar.

2. Drag & drop support: Drag the DataGrid item from the Toolbox to the window on the design surface.

a. Note: You may need to resize the window as well as work with the layout so the DataGrid fits as you would like.

3. Setup the ItemsSource for the DataGrid

a. In my example I’m going to use a DataTable that retrieves the Customers Table from the Northwind database. The code for that is in the sample on this post.

<Window.Resources>

<ObjectDataProvider x:Key="CustomerDataProvider"

ObjectType="{x:Type local:Customers}"

MethodName="GetCustomers" />

</Window.Resources>

<Grid>

<my:DataGrid Name="dataGrid1"

ItemsSource="{Binding Source={StaticResource CustomerDataProvider}}" />

</Grid>

b. As soon as the ItemsSource is set, the design surface should update to show you the data on the DataGrid. This is because DataGrid.AutoGenerateColumns is set to true by default.

4. Properties View grouping support: Now, click on the DataGrid in the design window and open the Properties View. Set the grouping to “Categorized”. You will find some groups that are specific to DataGrid such as the Columns group, GridLines group, Headers group, and Rows group.

a. In my example, from the Properties View I set EnableColumnVirtualization to true and AlternationRowBackground to LightGray

5. Now, right-click on the DataGrid in design view. You should see a DataGrid menu item with additional sub-items. The sub-items will be a little different depending if you have an ItemsSource set or not. Here is what it looks like with an ItemsSource set but no columns explicitly added:

When no ItemsSource is set, some sub-items will not appear. When explicit columns are set on the DataGrid, additional sub-items will be added. Now, let’s try out each of the options.

6. Generating columns all at once: Right-click on the DataGrid in design view. Select the DataGrid menu item, then select the “Generate Columns” sub-menu item. What just happened?

a. That may be a little confusing at first since the design view didn’t change. The design-time sets DataGrid.AutoGenerateColumns to false, then generates a list of columns with a one-to-one mapping of the data source’s properties and adds them to the columns collection in the xaml. Here is what my DataGrid looks like now in the xaml:

<my:DataGrid Name="dataGrid1" ItemsSource="{Binding Source={StaticResource CustomerDataProvider}}" EnableColumnVirtualization="True" AlternatingRowBackground="LightGray" AutoGenerateColumns="False">

<my:DataGrid.Columns>

<my:DataGridTextColumn Binding="{Binding Path=CustomerID}" Header="CustomerID" />

<my:DataGridTextColumn Binding="{Binding Path=CompanyName}" Header="CompanyName" />

<my:DataGridTextColumn Binding="{Binding Path=ContactName}" Header="ContactName" />

<my:DataGridTextColumn Binding="{Binding Path=ContactTitle}" Header="ContactTitle" />

<my:DataGridTextColumn Binding="{Binding Path=Address}" Header="Address" />

<my:DataGridTextColumn Binding="{Binding Path=City}" Header="City" />

<my:DataGridTextColumn Binding="{Binding Path=Region}" Header="Region" />

<my:DataGridTextColumn Binding="{Binding Path=PostalCode}" Header="PostalCode" />

<my:DataGridTextColumn Binding="{Binding Path=Country}" Header="Country" />

<my:DataGridTextColumn Binding="{Binding Path=Phone}" Header="Phone" />

<my:DataGridTextColumn Binding="{Binding Path=Fax}" Header="Fax" />

</my:DataGrid.Columns>

</my:DataGrid>

7. Removing all columns: Now that I have explicit columns set, if I wanted to clear them I can right-click on the DataGrid in design view, select DataGrid -> Remove Columns. This will remove all the columns from xaml but it will not change the AutoGenerateColumns property back to true.

8. Creating a column with the Add/Edit Columns editor: With all columns removed now, select DataGrid -> Add/Edit Columns… You should be presented with a column editor where the data sources properties are mapped on the left panel. The middle area is where you can choose the type of DataGridColumn to create and the right panel shows the columns that will be created.

a. Leave Type as Default and press the Add All button. You should see all the properties on the left panel moved to the right panel and mapped to columns. The default column is DataGridTextColumn.

b. Now, press the “Edit…” button on the first column in the right panel. An “Edit Column” editor should pop up with a list of common properties to set on the column.

c. Edit any of the fields of the columns you created and press ok on the “Add/Edit Columns” editor. The xaml should be updated with the set of columns you’ve created.

Summary

To recap, the cider design-time supports toolbox drag and drop, generating all columns, generating specific columns, editing columns, and removing columns. Remember that you have to set the ItemsSource on the DataGrid declaratively in order to get that functionality. The Properties View has also been updated for the DataGrid to support grouping of specific properties on the DataGrid. Please try it out and any feedback would be greatly appreciated.

Other Design-time Resources

Karl Shifflett has created this awesome tool called XAML Power Toys. Included in the tool is a utility for creating and customizing a WPF DataGrid. Check out the video walkthrough of it here.

WPF DataGrid – New Item Template Sample

Vincent Sibal - MSFT — Wed, 05 Nov 2008 18:33:00 GMT

This sample shows how to create a template for the NewItemPlaceholder to indicate that you can add a new item. This is what it will look like:

First I will need to create a new template specifically for the NewItemPlaceholder row. I’ve followed the general outline of the original DataGridRow control template but I’ve only included the pieces I needed and I’ve also added an element for the “Click here to add new item.” text. My template looks something like this:

<dg:SelectiveScrollingGrid>

…

…

</dg:SelectiveScrollingGrid>

</ControlTemplate>

Then I’m going to need to attach to several events. In particular, I need to hook up to the DataGrid.LoadingRow, DataGrid.UnloadingRow, DataGrid.RowEditEnding, and DataGridRow.MouseLeftButtonDown events.

I attach to the LoadingRow and UnloadingRow events so I can set either the default or new item control template when the row is created. These event handlers will look like this:

private void DataGrid_Standard_LoadingRow(object sender, DataGridRowEventArgs e)

{

if (_defaultRowControlTemplate == null)

{

_defaultRowControlTemplate = e.Row.Template;

}

if (e.Row.Item == CollectionView.NewItemPlaceholder)

{

e.Row.Template = _newRowControlTemplate;

e.Row.UpdateLayout();

}

private void DataGrid_Standard_UnloadingRow(object sender, DataGridRowEventArgs e)

{

if (e.Row.Item == CollectionView.NewItemPlaceholder && e.Row.Template != _defaultRowControlTemplate)

{

e.Row.Template = _defaultRowControlTemplate;

e.Row.UpdateLayout();

}

I attach to the DataGridRow.MouseLeftButtonDown event so that I can change the template of the NewItemPlaceholder on the first click. For this sample, when first clicking the row of the NewItemPlaceholder it immediate enters edit mode. Here is the handler:

private void Row_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)

{

DataGridRow row = sender as DataGridRow;

if (row.Item == CollectionView.NewItemPlaceholder && row.Template == _newRowControlTemplate)

{

// for a new row update the template and open for edit

row.Template = _defaultRowControlTemplate;

row.UpdateLayout();

DataGrid_Standard.CurrentItem = row.Item;

DataGridCell cell = Helper.GetCell(DataGrid_Standard, DataGrid_Standard.Items.IndexOf(row.Item), 0);

cell.Focus();

DataGrid_Standard.BeginEdit();

}

The last event is necessary so that the template is updated back to the new item template after a row is either committed or cancelled. It is a little tricky because what I really want is to perform my operation when the row is already committed or cancelled but the only event available, RowEditEnding, fires while the row is committing or being cancelled. What I can do is use the Dispatcher to make my operation take place after the RowEditEnding event. My handler looks like this:

private void DataGrid_Standard_RowEditEnding(object sender, DataGridRowEditEndingEventArgs e)

{

IEditableCollectionView iecv = CollectionViewSource.GetDefaultView((sender as DataGrid).ItemsSource) as IEditableCollectionView;

if (iecv.IsAddingNew)

{

// need to wait till after the operation as the NewItemPlaceHolder is added after

Dispatcher.Invoke(new DispatcherOperationCallback(ResetNewItemTemplate), DispatcherPriority.ApplicationIdle, DataGrid_Standard);

}

private object ResetNewItemTemplate(object arg)

{

DataGridRow row = Helper.GetRow(DataGrid_Standard, DataGrid_Standard.Items.Count - 1);

if (row.Template != _newRowControlTemplate)

{

row.Template = _newRowControlTemplate;

row.UpdateLayout();

}

return null;

}

So when I cancel or commit the edit on the new item, the new item template will be added back to the last row.

You can download the full sample here.

WPF VSM and DataGrid Sample

Vincent Sibal - MSFT — Wed, 05 Nov 2008 03:34:00 GMT

Now that the Visual State Manager (VSM) is part of the WPFToolKit, I thought I’d show a basic example of how to utilize VSM with the DataGrid. Some prereq’s and resources:

· You can download the toolkit here

· Info on getting VSM for WPF to work in Blend

· General VSM resource links

So, what I thought I would show is how to get it working with DataGridRows. The toolkit currently uses this VisualStateBehavior pattern to hook up the VisualStateManager to the control. If you take a look in the toolkit, you’ll find behavior classes for Button, Control, ListBoxItem, TextBoxBase, etc. They basically attach listeners of particular DPs and call VisualStateManager.GoToState as necessary.

The Functionality

In this sample I will create a DataGridRowBehavior class that will create visual states for:

· MouseOver

· Selected

· Editing

In the MouseOver state I want to make a somewhat subtle change to the background and for the Selected state I want to use the same background color but make it more illuminated. Here is what it will look like,

For the Editing state, I will use the same background color as the Selected state but I want it to pulse to signify this editable state. Unfortunately a picture will not be able to describe this behavior so you’ll have to download the sample to see it.

Implementation Details

First I’ll start with the DataGridRowBehavior class. This class derives from ControlBehavior and basically attaches to DPs to be notified on value changed. When it is notified, it calls VisualStateManager.GoToState on the particular state that it should be in. This is very similar to the standard way of creating a control with VSM behavior except it is using the attached behavior pattern instead. More on attached behavior’s here on John Gossman’s blog. So here is what my class will look like:

public class DataGridRowBehavior : ControlBehavior

{

protected override void OnAttach(Control control)

{

base.OnAttach(control);

DataGridRow dataGridRow = (DataGridRow)control;

Type targetType = typeof(DataGridRow);

EventHandler handler = delegate { UpdateState(dataGridRow, true); };

AddValueChanged(DataGridRow.IsMouseOverProperty, targetType, dataGridRow, handler);

AddValueChanged(DataGridRow.IsSelectedProperty, targetType, dataGridRow, handler);

AddValueChanged(DataGridRow.IsEditingProperty, targetType, dataGridRow, handler);

}

protected override void UpdateState(Control control, bool useTransitions)

{

DataGridRow dataGridRow = (DataGridRow)control;

if (dataGridRow.IsMouseOver)

{

VisualStateManager.GoToState(dataGridRow, "MouseOver", useTransitions);
}

else

{

VisualStateManager.GoToState(dataGridRow, "Normal", useTransitions);

}

if (dataGridRow.IsEditing)

{

VisualStateManager.GoToState(dataGridRow, "Editing", useTransitions);

}

else

{

VisualStateManager.GoToState(dataGridRow, "NotEditing", useTransitions);

}

if (dataGridRow.IsSelected)

{

VisualStateManager.GoToState(dataGridRow, "Selected", useTransitions);

}

else

{

VisualStateManager.GoToState(dataGridRow, "Unselected", useTransitions);

}

base.UpdateState(control, useTransitions);
}

}

From there you need to update the DataGridRow ControlTemplate to include the VisualStateGroups. I’ve taken the existing DataGridRow ControlTemplate and added two rectangles that will both overlap the main Border, “DGR_Border”. These rectangles will initially have an Opacity of zero and when a particular VisualState is triggered, the Opacity will be updated so that the appearance of the row’s background changes. To see the xaml for the full ControlTemplate, you can download the sample below.

For the VisualStateGroups, here are the groups I’ve set:

<VisualStateManager.VisualStateGroups>

</VisualStateGroup>

</VisualStateGroup>

</VisualStateGroup>

</VisualStateManager.VisualStateGroups>

Then for each state I setup a Storyboard to create the behavior for that state. Here is an example of MouseOver:

</Storyboard>

</VisualState>

fillColor represents one of the rectangles that I’ve added to the ControlTemplate. I do something similar with the Selected state and for the Editing state I create a pulsing effect by animating the rectangle’s Fill property with a different gradient brush that repeats forever.

With the VisualStateGroups setup, the last thing I have to do is register DataGridRowBehavior with the VisualStateBehavior property. This is how the VisualStateManager will recognize that my ControlTemplate makes use of VisualStateManager. I set that up in my DataGridRow style like so:

</Style>

So with that, here is the full sample. I did go over the implementation details pretty quickly so please take a look at the sample to see the full code and markup details. Stay tuned for more!

WPF DataGrid: Frozen Row Sample

Vincent Sibal - MSFT — Fri, 31 Oct 2008 23:27:00 GMT

It looks that this is a frequently requested feature and unfortunately didn't make the v1. It is still possible to extend the DataGrid to do so. A community developer has already posted a sample on creating a footer row for the DataGrid here, http://thibaud60.blogspot.com/2008/10/wpftoolkit-datagrid-with-footer-and.html. I thought I would post a sample for creating pinned rows starting from the top. This is similar to the excel pinning functionality.

I won't really go into too much implementation detail but I basically follow a similar pattern to the way frozen columns are implemented. The core of the code is in a CustomDataGridRowsPresenter.ArrangeOverride method. I tried to make it as simple as possible so it could be easily understood and as a result of that I didn't implement virtualization. Well, that's part of the reason I didn't implement virtualization. VirtualizingStackPanel isn't very extendable when it comes to it's virtualization and recycling functionality. I would have to do a good bit of my own implementation for it and it would take a good bit of time. So, the sample only works when row and column virtualization is turned off. If anyone feels up to making it work with virtualization, please be my guest. = )

Anyway, you can download the sample here. On the left pane I added buttons to increase/decrease the frozen row and column counts.

Note: The purpose of the sample is for learning purposes only. Please do not use this in production code as it is not fully tested.

WPF DataGrid - DataGridComboBoxColumn v1 Intro

Vincent Sibal - MSFT — Fri, 31 Oct 2008 17:49:00 GMT

Intro

If you haven't already, you can download the DataGrid v1 bits and source here. DataGridComboBoxColumn has had a make-over since the CTP release. In particular, the whole data binding story has been updated so that you can accomplish basic ComboBox tasks that before required some tedious workarounds. While other stock columns such as DataGridTextColumn and DataGridCheckBoxColumn use Binding for the visual to data hook up, DataGridComboBoxColumn uses a different route with three possible ways to hook up a binding. Here are the APIs that are specific to the DataGridComboBoxColumn:

public class DataGridComboBoxColumn : DataGridColumn

{

public string DisplayMemberPath { get; set; }

public IEnumerable ItemsSource { get; set; }

public virtual BindingBase SelectedItemBinding { get; set; }

public virtual BindingBase SelectedValueBinding { get; set; }

public string SelectedValuePath { get; set; }

public virtual BindingBase TextBinding { get; set; }

}

The three mechanisms to hook up the binding are:

· SelectedItemBinding

· SelectedValueBinding

· TextBinding

These three bindings basically map to the cell’s content being bound to ComboBox.SelectedItem, ComboBox.SelectedValue, or ComboBox.Text respectively. SelectedValuePath and DisplayMemberPath are convenience methods on a ComboBox control and apply to ComboBox.SelectedValuePath and ComboBox.DisplayMemberBinding respectively. Overall, you can think of these APIs as convenience methods that apply to the ComboBox element of the cell. Let’s go through some use cases.

Some examples

When the column is bound to a primitive data type such as int, string, or bool, and you want the ComboBox to have a list of similar items to choose from, you can use SelectedItemBinding like so:

<dg:DataGridComboBoxColumn SelectedItemBinding="{Binding ShipCity}">

<dg:DataGridComboBoxColumn.ItemsSource>

<col:ArrayList>

<sys:String>Redmond</sys:String>

<sys:String>Bellevue</sys:String>

<sys:String>Seattle</sys:String>

<sys:String>Renton</sys:String>

</col:ArrayList>

</dg:DataGridComboBoxColumn.ItemsSource>

</dg:DataGridComboBoxColumn>

ShipCity is a string type so the ComboBox.SelectedItem maps correctly to the item in the DataGrid’s column.

Let’s say I have a foreign key relationship between an Orders table and a Customers table. Orders contains a CustomerID foreign key and will be the ItemsSource for the DataGrid. I can setup a DataGridComboBoxColumn with Customers being its ItemsSource and hooking up the SelectedValueBinding like so:

<dg:DataGridComboBoxColumn SelectedValueBinding="{Binding CustomerID}"

SelectedValuePath="CustomerID"

DisplayMemberPath="ContactName"

Header="CustomerID (ContactName alias using SelectedValueBinding)"

ItemsSource="{Binding Source={StaticResource customerDataProvider}}">

SelectedValueBinding maps to Orders’ CustomerID, which also maps to Customers’ CustomerID through SelectedValuePath. I use DisplayMemberPath to alias the CustomerID with a more user friendly value to the end user.

You can download the solution to these examples here.

WPF DataGrid and the WPFToolKit have released!

Vincent Sibal - MSFT — Wed, 22 Oct 2008 17:10:00 GMT

Finally, the v1 WPF DataGrid is out! This is an out-of-band release that will be hosted on the WPF CodePlex site and integrated into the WPF Framework in vNext. You can download the bits as well as the source code here. You also may be pleased to hear that included with the WPFToolKit are other controls and features such as DatePicker, Calendar, and VSM! For any questions/feedback/issues you may have you can post them on the WPF CodePlex discussion list. Also, be sure to check our Tips & Tricks section on the CodePlex site for more resources and help.

So what’s new in the v1 WPF DataGrid? Here are some of the features that were not in the CTP:

· Row Validation

· Row Details

· Row Resizing

· Hidden Columns

· Column virtualization

· Read-only columns and cells

· Make-over of DataGridComboBoxColumn

· Design experience for the DataGrid in Cider and Blend

· UIAutomation support

· Star column width redesign

· Lots of bug fixes

There is a walkthrough of the feature set on windowsclient.net here and a hands-on lab that you can do here. I have updated the CTP Sample to include the new features. You can bind to all of the DataGrid and DataGridColumn properties in real-time and I also included samples for DataTable and Linq to SQL scenarios. You can download the sample here.

I also plan to update all my previous posts and samples with the updated bits. For better organization, I have made additional tags for DataGrid sample and DataGrid concepts. If you have any feedback or particular samples that you would like to see please let me know. Stay tuned for addtional material on the DataGrid, VSM, and more.

Breaking changes and how to update CTP code to v1

1. Update the xaml namespace from: xmlns:dg="clr-namespace:Microsoft.Windows.Controls;assembly=WpfToolkit" To: xmlns:dg=http://schemas.microsoft.com/wpf/2008/toolkit

2. Update the 'DataFieldBinding' property to 'Binding'

3. Update DataGridComboBoxColumn.DataFieldBinding to DataGridComboBoxColumn.SelectedItemBinding

4. Include this namespace in code behind, using Microsoft.Windows.Controls.Primitives;

WPF 3.5 SP1 sources are now available!

Vincent Sibal - MSFT — Wed, 22 Oct 2008 16:00:00 GMT

The Reference Source Code Center team has just announced that the WPF 3.5 SP1 sources are now publicly available. You can read about it here, http://blogs.msdn.com/rscc/archive/2008/10/22/wpf-sources-for-net-framework-3-5-sp1-are-available.aspx. The post also has pointers on how to setup and where to post any issues or feedback. Enjoy!

Overview of the editing features in the WPF DataGrid

Vincent Sibal - MSFT — Wed, 01 Oct 2008 17:50:00 GMT

Introduction

I’m going to talk a little on the editing features of the DataGrid. I will dive deep into a couple things but overall I just want to give you a good idea of the APIs you can work with and how to tweak a couple things. So basically I will be introducing a bit of the internal implementation that may be beneficial for you to understand, the editing commands and how to customize, and the editing events that are available.

Background on the data source and DataGrid working together

Some major updates were done in 3.5 SP1 to enable this editing scenario for the DataGrid. In particular, the IEditableCollectionView interface was added and ListCollectionView and BindingListCollectionView were updated to support this interface. Read more on IEditableCollectionView here. As a refresher, ListCollectionView is the view created for an ItemsControl when your data source implements IList such as ObservableCollection<T>. BindingListCollectionView is the view created for an ItemsControl when your data source implements IBindingList such as an ADO.net DataView.

The DataGrid uses IEditableCollectionView underneath the covers to support transactional editing as well as adding and removing data items. In the implementations of IEditableCollectionView in ListCollectionView and BindingListCollectionView, they both follow the IEditableObject pattern where the calls to IEditableCollectionView.EditItem, IEditableCollectionView.CancelEdit, and IEditableCollectionView.CommitEdit end up calling IEditableObject.BeginEdit, IEditableObject.CancelEdit, and IEditableObject.CommitEdit respectively. It is in the implementation of IEditableObject where you can provide the functionality to commit or rollback changes to the data source. For an ADO.net DataTable, you get this functionality for free as DataRowView already implements IEditableObject. When using an ObservableCollection<T> you will have to provide your own implementation for IEditableObject for T. See the MSDN documentation of IEditableObject for an example of how to implement it for a data item.

Things to keep in mind:

· DataGrid checks for IEditableCollectionView’s CanAddNew, CanCancelEdit, and CanRemove properties before executing the EditItem, CancelEdit, or CommitEdit methods. So if editing appears to not work for some reason, be sure to check that it is able to edit.

	ListCollectionView	BindingListCollectionView
CanAddNew	True if there is not an edit transaction occurring, if the collection is not a fixed size, and if it can create an object of the correct type.	True if there is not an edit transaction occurring, if the collection is not a fixed size, and if the collection is not read-only.
CanCancelEdit	True if the edited item implements the IEditableObject interface.	True if the edited item implements the IEditableObject interface.
CanRemove	True if the collection is not a fixed size and if an add or edit transaction is not occurring.	True if the collection is not a fixed size and if an add or edit transaction is not occurring and if the collection is not read-only.

For information on how the data binding is hooked to the UI, see this post on Stock and Template Columns and Dissecting the Visual Layout.

Note about DataGrid properties related to editing

There are three properties on DataGrid to control editing/adding/deleting. These properties are:

· CanUserAddRows

· CanUserDeleteRows

· IsReadOnly (not in CTP)

They are basically self-documenting but beware of CanUserAddRows and CanUserDeleteRows as they can appear a little magical. Their values are coerced based on other properties such as DataGrid.IsReadOnly, DataGrid.IsEnabled, IEditableCollectionView.CanAddNew, and IEditableCollectionView.CanRemove. So this is another thing to watch out for when editing. If you run into a situation where you set CanUserAddRows or CanUserDeleteRows to true but it is changed to false automatically, check that the conditions below are met.

CanUserAddRows	True if the DataGrid is not ReadOnly and IsEnabled, CanUserAddRows is set to true and IEditableCollectionView.CanAddNew is true
CanUserDeleteRows	True if the DataGid is not ReadOnly and IsEnabled, CanUserDeleteRows is set to true and IEditableCollectionView.CanRemove is true

Working with editing commands

Default commands have been added to the DataGrid to support editing. These commands and their default input bindings are:

· BeginEditCommand (F2)

· CancelEditCommand (Esc)

· CommitEditCommand (Enter)

· DeleteCommand (Delete)

When each command is executed it will do some internal housekeeping and at some point it will call into its IEditableCollectionView counterpart. For example, BeginEditCommand calls into IEditableCollectionView.EditItem and CancelEditCommand calls into IEditableCollectionView.CancelItem.

DataGrid also has APIs where you can call editing commands programmatically. Not surprisingly, the APIs are BeginEdit, CancelEdit, and CommitEdit.

Adding new input gestures

Adding new input gestures is similar to any other control in WPF. The DataGrid commands are added through the CommandManager so one possible solution would be to register a new InputBinding with the CommandManager:

CommandManager.RegisterClassInputBinding(

typeof(DataGrid),

new InputBinding(DataGrid.BeginEditCommand, new KeyGesture(Key.<new key>)));

Disabling commands

You can disable any of the editing commands by attaching to the CommandManager.CanExecuteEvent, looking for the command to disable, then setting e.CanExecute accordingly. Here is an example:

_handler = new CanExecuteRoutedEventHandler(OnCanExecuteRoutedEventHandler);

EventManager.RegisterClassHandler(typeof(DataGrid), CommandManager.CanExecuteEvent, _handler);

void OnCanExecuteRoutedEventHandler(object sender, CanExecuteRoutedEventArgs e)

{

RoutedCommand routedCommand = (e.Command as RoutedCommand);

if (routedCommand != null)

{

if (routedCommand.Name == "<command name>")

{

e.CanExecute = <some condition>;

if(!e.CanExecute)

e.Handled = true;
}
}

}

This is a relatively cumbersome way of disabling an editing command from being executed. Fortunately events were added to the DataGrid so that they can be canceled in a more direct fashion (although no direct event exists for the DeleteCommand).

Editing events on the DataGrid

These are the editing events that you can listen to and cancel the operation or modify data:

· RowEditEnding

· CellEditEnding

· BeginningEdit

· PreparingCellForEdit

· InitializingNewItem

In the first three events; RowEditEnding, CellEditEnding, and BeginningEdit, you have access to the DataGridRow and DataGridColumn that is being committed, cancelled, or edited. These events are called right before the actual operation will occur. You have the ability to cancel the operation completely by setting e.Cancel to true. RowEditEnding and CellEditEnding both have a parameter EditAction which lets you know if it is a commit or cancel action. From CellEditEnding, you also have access to the editing FrameworkElement. This gives you the ability to set or get properties on the visual itself before a cell commit or cancel.

PreparingCellForEdit is fired right after the cell has changed from a non-editing state to an editing state. In this event you have the ability to modify the contents of the cell. InitializingNewItem is called when a new item is added and in this event you have the option to set any properties on the newly created item. This event is good when you want to set initial default values on a new item.

Summary

So hopefully this will give you an idea on what APIs you have available for editing scenarios as well as some gotchas on how particular editing features work. If there is other editing questions/topics that you would like to read about please let me know. Another item that I plan to discuss in the future is how row validation will be tied into the DataGrid, so stay tuned!

Check out the WPF Application Quality Guide v0.3

Vincent Sibal - MSFT — Mon, 29 Sep 2008 07:46:00 GMT

The WPF Application Quality Guide v0.3 has just released! For more information on it, check out Ivo's blog post here. I especially like the new road map section on the different personas and suggested readings.

Pasting content to new rows on the WPF DataGrid

Vincent Sibal - MSFT — Thu, 25 Sep 2008 17:59:00 GMT

On a previous post I talked about how to implement Clipboard.Paste for the DataGrid. The functionality was such that you could only paste to existing rows and cells. I got a customer request on how to paste to new rows so I thought I’d capture it here.

If you want to be able to paste to new rows, you just need to call IEditableCollectionView.AddNew before pasting to that row and optionally update selection. Here is the updated OnExecutePaste code to the previous sample,

protected virtual void OnExecutedPaste(ExecutedRoutedEventArgs args)

{

// parse the clipboard data

List<string[]> rowData = ClipboardHelper.ParseClipboardData();

bool hasAddedNewRow = false;

// call OnPastingCellClipboardContent for each cell

int minRowIndex = Items.IndexOf(CurrentItem);

int maxRowIndex = Items.Count - 1;

int minColumnDisplayIndex = (SelectionUnit != DataGridSelectionUnit.FullRow) ? Columns.IndexOf(CurrentColumn) : 0;

int maxColumnDisplayIndex = Columns.Count - 1;

int rowDataIndex = 0;

for (int i = minRowIndex; i <= maxRowIndex && rowDataIndex < rowData.Count; i++, rowDataIndex++)

{

if (CanUserPasteToNewRows && CanUserAddRows && i == maxRowIndex)

{

// add a new row to be pasted to

ICollectionView cv = CollectionViewSource.GetDefaultView(Items);

IEditableCollectionView iecv = cv as IEditableCollectionView;

if (iecv != null)

{

hasAddedNewRow = true;

iecv.AddNew();

if (rowDataIndex + 1 < rowData.Count)

{

// still has more items to paste, update the maxRowIndex

           maxRowIndex = Items.Count - 1;
          }
        }

}

else if (i == maxRowIndex)

{

continue;
}

int columnDataIndex = 0;

for (int j = minColumnDisplayIndex; j < maxColumnDisplayIndex && columnDataIndex < rowData[rowDataIndex].Length; j++, columnDataIndex++)

{

DataGridColumn column = ColumnFromDisplayIndex(j);

column.OnPastingCellClipboardContent(Items[i], rowData[rowDataIndex][columnDataIndex]);

}

// update selection

if (hasAddedNewRow)

{
UnselectAll();

UnselectAllCells();

CurrentItem = Items[minRowIndex];

if (SelectionUnit == DataGridSelectionUnit.FullRow)

{

SelectedItem = Items[minRowIndex];

}

else if (SelectionUnit == DataGridSelectionUnit.CellOrRowHeader || SelectionUnit == DataGridSelectionUnit.Cell)

    {
      SelectedCells.Add(new DataGridCellInfo(Items[minRowIndex],   Columns[minColumnDisplayIndex]));
    }
}

}

So with this new logic you can paste a set of rows starting at the NewItemPlaceholder and it will create a set of new rows where all the content will be pasted. For the selection logic, I just made it pretty basic and didn’t really enforce any specific requirements. Other than that, I just added one DP, CanUserPasteToNewRows, just to turn it on and off for this example. Here is the updated solution.

WPF DataGrid - Clipboard Paste Sample

Vincent Sibal - MSFT — Fri, 19 Sep 2008 17:55:00 GMT

In the v1 release (and CTP) of the WPF DataGrid there will be support for Clipboard.Copy but no support out of the box for Clipboard.Paste. However, there is extensibility support for Clipboard.Paste which I will show how to implement in this post.

In DataGridColumn.cs an additional API, OnPastingCellClipboardContent, exists so you can add pasting functionality to each DataGridCell. A similar API, OnCopyingCellClipboardContent, also exists and behaves the same way except it is used from copying content. OnPastingCellClipboardContent has two parameters; item, which is the particular data item in the list of DataGrid.Items to update, and cellContent, which is the actual content to add to the cell itself.

So with that in mind, what I need to do is get the content currently on the clipboard, parse the data, and then call OnPastingCellClipboardContent for each cell. I’m also going to setup a command that is similar to the Copy command and I’ve decided to subclass DataGrid. Here is the code for creating the command:

public class CustomDataGrid : DataGrid

{

static CustomDataGrid()

{

CommandManager.RegisterClassCommandBinding(

typeof(CustomDataGrid),

new CommandBinding(ApplicationCommands.Paste,

new ExecutedRoutedEventHandler(OnExecutedPaste),

new CanExecuteRoutedEventHandler(OnCanExecutePaste)));
}

…

}

In the copy scenario, the OnCanExecuteCopy only fires if you have selected cells. For the onCanExecutePaste scenario I want it to be such that you can paste content as long as any particular cell is selected. So in my OnCanExecutePaste method, I only need the CurrentCell to not be null.

protected virtual void OnCanExecutePaste(CanExecuteRoutedEventArgs args)

{

args.CanExecute = CurrentCell != null;

args.Handled = true;

}

Before getting into OnExecutePaste, I want to talk just a little bit about the parsing stuff. I created a simple parser for CSV and Text format. The algorithms are pretty straightforward so I’m not going to show them here. The parser should work when copying data from the WPF DataGrid as well as copying Excel data to the WPF DataGrid. For Excel data I’m using the Text parser. What the parser returns is a list of a list which basically represent the rows and cells of a DataGrid.

So in my OnExecutePaste method, I am going to iterate through the set of cells starting at the CurrentCell. It is possible that the set of content to be pasted is more than the set of cells to paste them in or visa-versa. So I need to keep track of the max rows and columns that can be pasted to as well as the max data that can be placed in the cells. Here is the code snippet:

protected virtual void OnExecutedPaste(ExecutedRoutedEventArgs args)

{

// parse the clipboard data

List<string[]> rowData = ClipboardHelper.ParseClipboardData();

// call OnPastingCellClipboardContent for each cell

int minRowIndex = Items.IndexOf(CurrentItem);

int maxRowIndex = Items.Count - 1;

int minColumnDisplayIndex = (SelectionUnit != DataGridSelectionUnit.FullRow) ? Columns.IndexOf(CurrentColumn) : 0;

int maxColumnDisplayIndex = Columns.Count - 1;

int rowDataIndex = 0;

for (int i = minRowIndex; i < maxRowIndex && rowDataIndex < rowData.Count; i++, rowDataIndex++)

{

int columnDataIndex = 0;

for (int j = minColumnDisplayIndex; j < maxColumnDisplayIndex && columnDataIndex < rowData[rowDataIndex].Length; j++, columnDataIndex++)

{

DataGridColumn column = ColumnFromDisplayIndex(j);

column.OnPastingCellClipboardContent(Items[i], rowData[rowDataIndex][columnDataIndex]);

}

I did make one condition when SelectionUnit is equal to FullRow. For that scenario when users copy a full row and paste to another full row the column index should not matter as their intention is to paste the entire row to the new row. So for that I set minColumnDisplayIndex to 0.

You can check out the full sample here. For more information on clipboard paste see this post which is another sample.

Other DataGrid Samples:

ScrollViewer with ToolTip

Custom sorting, column selection, single-click editing

Tri-state sorting

Styling rows and columns based on header conditions