Vincent Sibal's Blog : WPF 3.5 SP1

WPF 3.5 SP1 sources are now available!

vinsibal — 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!

WPF 3.5 SP1 Feature: BindingGroups with Item-level Validation

vinsibal — Tue, 12 Aug 2008 07:14:00 GMT

Motivation

Before 3.5 SP1, the binding validation system worked with only one binding at a time. What made this difficult in some scenarios was when validation was required on a set of bound objects. Some typical examples that come to mind are a form of data items that are submitted all at once or a ListView or DataGrid row that is committed all at once. You can put a validation rule on each bound object and validate their values individually but there was no readily available way in the binding validation system to validate multiple objects together. Now in 3.5 SP1 a solution has been created for this, Binding Groups.

What is it?

A BindingGroup encapsulates and has access to a set of related bindings. These related bindings are bindings that share the same data context as the BindingGroup and/or bindings that have explicitly declared membership to the BindingGroup. With this set of bindings, the BindingGroup can now provide services such as validation of all the encapsulated bindings together and transactional editing.

How do I define a BindingGroup?

We will use an example to illustrate how to define a BindingGroup. Let’s say this is the data context that I will use (I just went canoeing recently which influence my choice of data):

public class BoatRentalCustomer

{

public string FirstName { get; set; }

public string LastName { get; set; }

public DateTime? DateOfBirth { get; set; }

public int BoatCheckOutID { get; set; }

public DateTime? StartDate { get; set; }

public DateTime? EndDate { get; set; }

}

With this data I want to use it in a form to be filled in by the customer. Here is the xaml (I only put the relevant information for this example):

<Grid>

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

As I said in the Motivation section, we can add validation to each binding and validate them individually, but there wasn’t a built in mechanism to validate them as a group. To do that, we can add a BindingGroup to the Grid:

<Grid>

<Grid.BindingGroup>

<BindingGroup.ValidationRules>

...

</BindingGroup.ValidationRules>

</BindingGroup>

</Grid.BindingGroup>

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

Assuming that I’ve set the Grid.DataContext to be an instance of BoatRentalCustomer, the BindingGroup I set on the Grid will have access to all the bindings I set within the Grid. This example shows how the BindingGroup gets bindings from the same DataContext but it is also possible to get bindings through explicit membership declaration like this slightly modified example below:

<Grid>

<Grid.BindingGroup>

<BindingGroup.ValidationRules>

...

</BindingGroup.ValidationRules>

</BindingGroup>

</Grid.BindingGroup>

<TextBox Text="{Binding Path=FirstName}"

FontSize="{Binding ElementName=sliderFontSize,

Path=Value,

BindingGroupName=FormBindingGroup}" />

<Button Click="submit_Click">Submit</Button>

</StackPanel>

</Grid>

I named the BindingGroup, “FormBindingGroup”, and added a binding to the FontSize property on one of the TextBox elements. Notice that in the binding I explicitly declare BindingGroupName to be set to “FormBindingGroup”. By doing this, the BindingGroup will have access to the bindings under the same DataContext as well as the bindings associated with it by the same BindingGroupName. The ability to declare explicit membership to a BindingGroup are for scenarios where bindings don’t use DataContext (explicit Source or ElementName like in the example above) and/or bindings that use a different DataContext that want to participate in the same group validation.

From the previous example you saw that Grid had a property named BindingGroup. You may be wondering where BindingGroup is actually defined. BindingGroup has been added to FrameworkElement and FrameworkContentElement so it can be associated with a set of bindings on a per element basis.

public class Framework[Content]Element

{

public static readonly DependencyProperty BindingGroupProperty;

public BindingGroup BindingGroup { get; set; }

}

It has also been added to ItemsControl so it can be associated with a set of bindings per each generated container. The pattern is similar to ItemTemplate.

public class ItemsControl

{

public static readonly DependencyProperty ItemBindingGroupProperty;

public BindingGroup ItemBindingGroup { get; set; }

}

And as you saw the use of BindingGroupName, that property has been defined in BindingBase.

public class BindingBase

{

public string BindingGroupName { get; set; }

}

How do I use it? (Part 1)

So now I know where to define a BindingGroup and how bindings get associated with it, but how do I use it? Let’s first look at the BindingGroup class and then dig into the common APIs and common scenarios. Here is the BindingGroup class:

public class BindingGroup : DependencyObject

{

public Collection<BindingExpressionBase> BindingExpressions { get; }

public bool CanRestoreValues { get; }

public IList Items { get; }

public string Name { get; set; }

public bool NotifyOnValidationError { get; set; }

public Collection<ValidationRule> ValidationRules { get; }

public void BeginEdit();

public void CancelEdit();

public bool CommitEdit();

public object GetValue(object item, string propertyName);

public bool TryGetValue(object item, string propertyName, out object value);

public bool UpdateSources();

public bool ValidateWithoutUpdate();

}

You have access to the associated bindings through the BindingExpressions property and can set group validation rules through the ValidationRules property. You may have notice all these transactional methods in this class such as BeginEdit, CancelEdit, etc. Well, as part of group validation you have the ability to control whether the new data to that item is committed as a whole and/or reverted back to its previous state. The two major areas of BindingGroup that I want to get into are its validation rules and how its methods are used to update the binding sources. First, let’s discuss validation.

The ValidationRule class has been updated with a couple APIs to work with BindingGroup. Here are the new APIs:

public abstract class ValidationRule

{

public bool ValidatesOnTargetUpdated { get; set; }

public ValidationStep ValidationStep { get; set; }

}

public enum ValidationStep

{

RawProposedValue = 0,

ConvertedProposedValue = 1,

UpdatedValue = 2,

CommittedValue = 3,

}

The ValidationStep property is used to let ValidationRule know when to apply the validation. RawProposedValue means the rule is applied to the unconverted value. This is the default step which also was the current behavior for ValidationRule prior to this feature. ConvertedProposedValue means the rule is applied to the converted value, UpdatedValue means the rule is applied after writing to the source, and CommittedValue means the rule is applied after committing changes. ValidatesOnTargetUpdated is used to trigger validation when the source is updating the target.

So now we have an idea of how validation rule may be used but how does this relate to the transactional methods of BindingGroup? Note that to use a BindingGroup for transactional editing, you should define IEditableObject on your data item.

BeginEdit, CancelEdit, and CommitEdit work similar to IEditableCollectionView’s versions where they will call IEditableObject.BeginEdit, IEditableObject.CancelEdit, and IEditableObject.EndEdit respectively on the data item. In addition to CommitEdit, you also have UpdateSources and ValidateWithoutUpdate. These three methods (CommitEdit, UpdateSources, and ValidateWithoutUpdate) are the main methods that you will call to validate and update your source. That brings up a point on how bindings update in a BindingGroup. UpdateSourceTrigger for bindings that belong to the BindingGroup are set to Explicit by default. That means you will need to use the BindingGroup APIs to update the bindings (CommitEdit or UpdateSources). Validation and updating methods work like this:

· ValidateWithoutUpdate: runs all validation rules marked as RawProposedValue or ConvertedProposedValue.

· UpdateSources: does the same as ValidateWithoutUpdate, and then if no errors were found, it writes all the values to the data item and runs the validation rules marked as UpdateValue.

· CommitEdit: does the same as UpdateSources, and then runs the rules marked as CommittedValue.

How do I use it? (Part 2)

Ok, we made it this far. So I know where to define my BindingGroup, how to setup when I want my validation rules ran and how to update my bindings. Let’s look at what kinds of things I can do to actually validate the item inside the ValidationRule.Validate method.

The value input parameter to Validate is the actual BindingGroup. With the BindingGroup you can query for the data on the item. The important BindingGroup APIs for the actual validation include Items, GetValue, and TryGetValue. The Items collection contains the unique data items used by the bindings in the group. GetValue looks for the binding that uses the given item and propertyName parameter values and returns the value appropriate to the current validation step. So for example, if the validation step is RawProposedValue or ConvertedProposedValue, the data source has not been updated yet when the Validate method is called, but by querying for the value using GetValue you can get what the value will be (as long as it passes validation). Here is an example Validate method:

public override ValidationResult Validate(object value, CultureInfo cultureInfo)

{

BindingGroup bindingGroup = (BindingGroup)value;

BoatRentalCustomer customer = (BoatRentalCustomer)bindingGroup.Items[0];

object startDateObj = bindingGroup.GetValue(customer, "StartDate");

DateTime? startDate = DateTime.Parse((string)startDateObj);

object endDateObj = bindingGroup.GetValue(customer, "EndDate");

DateTime? endDate = DateTime.Parse((string)endDateObj);

// check start and end date together

if (startDate.Value > endDate.Value)

{

return new ValidationResult(false, string.Format(

"StartDate: {0}, cannot be greater than EndDate: {1}",

startDate,

endDate));

}

else

{
return new ValidationResult(true, null);
}

}

You’ll notice that I am assuming the data item is Items[0]. If the BindingGroup has bindings from more than one data source then you will have to handle that as the Items collection will be greater than one. I’ve also been pretty optimistic about getting the proposed values as well as parsing the DateTime. This example is for demonstration purposes only but in a production level application you will probably want to use TryGetValue and TryParse. So inside the Validate method I have access to the entire item and in the example I validate the start and end date together.

Where we are…

Hopefully I still have your attention after all that. I know it’s a lot to go through. Just to summarize a bit, a BindingGroup enabled you to validate data at the item-level as opposed to the property-level. This is possible because the BindingGroup has access to all the bindings associated with the data item (assuming you set the BindingGroup that way). BindingGroup is available on all FrameworkElements, FrameworkContentElements, and ItemsControls. You set the validation rules on the actual BindingGroup and in the ValidationRule.Validate method you are given the BindingGroup where you can query for all the properties on the item being validated. I’ve attached a small sample to demonstrate some of the concepts discussed here.

So what’s left? Well, there are two more important topics that should be discussed. One is the new additions to validation feedback and the other is how BindingGroup works in conjunction with IEditableCollectionView. I will save both these topics for another post as there is enough here to digest. This does cover about 95% of the new APIs relating to BindingGroup so there isn’t too much more to cover. = )

However, BindingGroup and IEditableCollectionView can be a bit confusing on when and how to use them so I do want to talk more on that. Read more on BindingGroup and IEditableCollectionView here. And you can read on BindingGroup and ValidationFeedback here.

.NET 3.5 SP1 and WPF DataGrid CTP are out now!

vinsibal — Tue, 12 Aug 2008 06:00:00 GMT

UPDATE: the WPF DataGrid v1 has just released. For more information, see this post. The information below still applies, but the new post contains the additional features as well as an updated sample. Check it out!

As you might have heard, .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 are out today! There are a ton of blogs that point to the download links so I’ll just point you over to one of them, Lester’s blog. In addition to the SP1 release, the WPF DataGrid CTP is also out today! Check it out here for the list of DataGrid features as well as 3.5 SP1 features in the Controls area that has enabled the DataGrid. Our awesome PM, Samantha, has a nice video introducing the basic usage of the DataGrid. Oh yea, and you can download the binaries and source code here! 3.5 SP1 is required to use the DataGrid binaries so be sure to download that goodness.

Overview

Does DataGrid need an introduction? Well, maybe I’ll just point out some of the WPF specifics to get you started. DataGrid subclasses from MultiSelector which subclasses from Selector which subclasses from ItemsControl. So like ListBox or ComboBox, DataGrid is an extention of an ItemsControl. With that in mind, the DataGrid has the concept of rows and cells but to match the pattern of ItemsControl, the collection of rows is the Items property. Cells are sub-items of a particular item and are defined by the DataGrid.

How do I use it?

There are a ton of sub-features and ways to customize and tweak the DataGrid. For this first post I just want to start with the very basics. Ok, here we go. DataGrid derives from ItemsControl, so just like we’ve done in the past with ListBox, bind the DataGrid.ItemsSource to your data source.

<dg:DataGrid ItemsSource="{Binding Source={StaticResource people}}">

In this example people represents a collection that derives from ObservableCollection<Person> where Person has some properties that represent a general person (first name, last name, id, etc). Ok, that’s it. If you run a project with that you will get a full set of rows and columns with each cell bound to each property on the Person item. By default the DataGrid will auto-generate columns for you and the generated columns will be a specific type of column based on the type of properties you have in your data source. It also automatically creates the necessary bindings for each data source property on each column. It does appear very magical but hopefully I will be able to demystify a lot of its behavior over a series of posts. Here are some other things you get or can do right out of the box as an end-user for CTP:

· Resize columns: hover over the end of a header, then click and drag.

· Reorder columns: click on a column header and drag over a different area.

· Auto-sort data in a column: click on a column header and the items in the column will toggle from ascending to descending

· Multi-column sorting: SHIFT + click on multiple column headers

· Selection: Default mode is FullRow and multi-row selection

· Navigation: all the basic navigation you expect in a spreadsheet

· Edit cells and rows: select a column and press F2 or double-click to open the cell for edit. Press ‘ESC’ to cancel and/or ‘Enter’ to commit the changes.

· Delete rows: select a row and press ‘Delete’.

· Add new rows: navigate to the bottom row and double click a cell to open it for edit.

· Clipboard Copy

· Freeze columns

Of course there is a bunch more you can do to customize these default features as well as the internals of the DataGrid. I’m going to do a series of posts introducing many of the sub-areas of DataGrid. In the meantime, I made a sample where I bind many of the DataGrid DPs to CheckBoxes and ComboBoxes so you can tweak things in real-time and play around with it. Enjoy!

UPDATE: You can also download the updated V1 Sample here.

I'm also going to be doing a series of posts on the DataGrid. I'll be updating this with the future DataGrid posts.

Learn more:

Dissecting the Visual Layout

Stock and Template Columns

Working with DataGridComboBoxColumn (Part1)

Working with DataGridComboBoxColumn (Part2)

Overview of the editing features in the DataGrid

Design-time Walkthrough

5 Random Gotchas with the WPF DataGrid

Samples:

ScrollViewer with ToolTip

Custom sorting, column selection, single-click editing

Tri-state sorting

Styling rows and columns based on header conditions

Clipboard Paste

Locking input to the row being edited

Dynamically updating a DataGridComboBoxColumn

New Item Template

Frozen Row Sample

Exploring MVVM: Grouping with the DataGrid

Launching a custom dialog to edit items in the DataGrid

WPF 3.5 SP1 Feature: Alternating Rows

vinsibal — Thu, 29 May 2008 08:50:00 GMT

So what else is new in WPF 3.5 SP1? Here is a smaller but pretty nice feature for you ItemsControl fans: alternating rows.

This alternating row feature has been added in WPF 3.5 SP1 to make it easier to set properties like Background, Foreground, etc. on the rows of an ItemsControl in alternating fashion. Two new properties have been added to ItemsControl.

public class ItemsControl : Control, IAddChild, IGeneratorHost

{
public int AlternationCount { get; set; }

public static readonly DependencyProperty AlternationCountProperty;

public static readonly DependencyProperty AlternationIndexProperty;

public static void SetAlternationIndex(DependencyObject element, int index){ }
}

AlternationCount is basically the count that the sequence will alternate on. It is set to the value 0 by default which means it is turned off. AlternationIndex is an attached property that gets set on each container item and will have a value in the range of [0, AlternationCount). Some examples may clarify its usage.

Here is a ListView that sets the AlternationCount to 2 and uses triggers for the AlternationIndex to change the background color.

<Style.Triggers>

</Trigger>

</Trigger>

</Style.Triggers>

</Style>

<ListView ItemContainerStyle="{StaticResource alternatingListViewItemStyle}"

AlternationCount="2" />

With the AlternationCount set to 2, the AlternationIndex can be set to 0 or 1. On every AlternationIndex set to 1, I’m going to set the background to blue.

Notice that I also have a trigger when the AlternationIndex is set to 2, however, the current range for my AlternationIndex is [0, AlternationCount) so this trigger will not fire. If I do set the AlternationCount to 3, I will get something like this,

AlternationCount has also been added the HierarchicalDataTemplate and GroupStyle. Here are some examples of both. Oh, and you can also set properties with the AlternationIndex through a converter which I also have an example for below.

Here is the usage with a GroupStyle:

<ListView.GroupStyle>

<GroupStyle.HeaderTemplate>

…

</GroupStyle.HeaderTemplate>

<GroupStyle.ContainerStyle>

…

<Style.Triggers>

</Trigger>

</Style.Triggers>

</Style>

</GroupStyle.ContainerStyle>

</ListView.GroupStyle>

Here is one using the HierarchicalDataTemplate (I don’t show it here but I could set different alternation counts for each treeview level if I wanted to):

</HierarchicalDataTemplate>

</HierarchicalDataTemplate>

</DataTemplate>

Here is an example of using a converter to set properties on the control.

<Setter Property="Background" Value="{Binding

RelativeSource={RelativeSource Self},

Path=(ItemsControl.AlternationIndex),

Converter={StaticResource BGConverter}}"/>

</Style>

<TreeView Name="mytv2"

ItemContainerStyle="{StaticResource alternatingTreeViewItemStyle}"

AlternationCount="2" />

// code for convert function

public object Convert(object value, Type targetType, object parameter, CultureInfo culture)

{
switch ((int)value)

{
case 1:

return Brushes.LightBlue;

case 2:

return Brushes.LightGray;

default:

return Brushes.White;
}
}

Remember that you aren’t restricted to background color. You can use any DP on the items control to alternate. I’ve attached a project that has all the above examples for you to try out and explore.

Using IEditableCollectionView with dynamically generated GridViewColumns

vinsibal — Wed, 28 May 2008 02:29:00 GMT

I recently got a question on how to implement IEditableCollectionView with GridViewColumns that are dynamically created. Creating the columns dynamically actually doesn’t really have a big impact on IEditableCollectionView implementation. I have a sample below that dynamically adds columns but really does not differ all that much from the first sample.

Side note:

There are some design issues to think about when you want to design with an IEditableCollectionView. If you recall from the first sample I used, I relied on the template (TextBlock for non-editable, TextBox for editable) to control the user from being able to edit an item. Since a TextBox has two-way binding by default, it was actually changing the data source when in edit mode. Implementing IEditableObject and keeping a copy was my mechanism to revert changes if the user wanted to cancel the operation. There is actually another (more optimal) solution that leverages another new feature, but I’m going to have to leave that for a separate post. The new feature is actually briefly mentioned on Jossef’s post for new perf improvements in WPF 3.5 SP1 under Controls Improvements. You can probably already guess what it is, but I won’t say anything for now.

Back to the task at hand:

I want to create columns dynamically and use IEditableCollectionView. I decided to create the column templates in code and create columns for each public property of the data source. The default template is a TextBlock that binds to the particular property of the data source.

// automatically creates GridViewColumns based on the public properties

private void GenerateGridView(Type type)

{

GridView gridView = new GridView();

foreach (PropertyInfo pi in type.GetProperties(BindingFlags.Public | BindingFlags.Instance))

{

GridViewColumn column = new GridViewColumn();

// set the header

column.Header = pi.Name;

// the default cell template

FrameworkElementFactory cellTemplateFactory = new FrameworkElementFactory(typeof(TextBlock));

Binding binding = new Binding(pi.Name);

cellTemplateFactory.SetBinding(TextBlock.TextProperty, binding);

DataTemplate defaultCellTemplate = new DataTemplate();

defaultCellTemplate.VisualTree = cellTemplateFactory;

column.CellTemplate = defaultCellTemplate;

gridView.Columns.Add(column);

}

this.itemsList.View = gridView;

}

Before when I wanted to make an item editable, I changed the ListBoxItem template to a TextBox. Since I’m using columns now, there are some changes to the visual tree being used, and I cannot just change the whole ListBoxItem to a TextBox. Oh, and now that I’m using ListView, they are ListViewItems now and not ListBoxItems.

When using a GridView as the View, the ListViewItem uses a GridViewRowPresenter which will contain ContentPresenters for each column. Now each time I have to update the item’s template, I’m going to drill down into the ListViewItem and update the cell template of each ContentPresenter to be a TextBox.

private void UpdateContentTemplate(bool isEditing, ListViewItem lvi)

{

// get the content presenter of the particular column
GridViewRowPresenter rowPresenter = this.GetVisualChild<GridViewRowPresenter>(lvi);

// go through each column and update the content template

int columnIndex = 0;

foreach (GridViewColumn column in rowPresenter.Columns)

{

// get the content presenter of the particular column
ContentPresenter cp = this.GetVisualChild<ContentPresenter>(rowPresenter, columnIndex);

DataTemplate cellTemplate = new DataTemplate();

FrameworkElementFactory cellTemplateFactory;

// if editing, set the template to a textbox, else to a textblock

if (isEditing)

{
cellTemplateFactory = new FrameworkElementFactory(typeof(TextBox));

Binding binding = new Binding(column.Header.ToString());

binding.UpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged;

cellTemplateFactory.SetBinding(TextBox.TextProperty, binding);
}

else

{
cellTemplateFactory = new FrameworkElementFactory(typeof(TextBlock));

Binding binding = new Binding(column.Header.ToString());

cellTemplateFactory.SetBinding(TextBlock.TextProperty, binding);
}

cellTemplate.VisualTree = cellTemplateFactory;

cp.ContentTemplate = cellTemplate;

columnIndex++;
}
}

The rest of the code is basically the same as in the first sample (with some refactoring). Adding/Removing/Editing all work the same and there are no changes to the data source. For kicks I added commands in addition to the buttons since I was getting tired of having to mouse down to the buttons each time I wanted to edit and submit. The commands are, F2 = Edit, Enter = Submit, Esc = Cancel. Note that this isn’t the most efficient but hopefully it will give you some ideas to expand on. Here is the project.

WPF 3.5 SP1 Feature: Non-live Scrolling

vinsibal — Thu, 22 May 2008 17:40:00 GMT

So far for the new WPF 3.5 SP1 features, I've surveyed Item Container Recycling, Data Formatting, and IEditableCollectionView. Next on my list is Non-live Scrolling!

What is it?

Before 3.5 SP1, the WPF ScrollViewer only supported live scrolling, which means the view of content the ScrollViewer contains updates immediately as the user moves the ScrollBar. For controls like ItemsControl that had large data sets, live scrolling performance often looked sluggish. Now in SP1, app developers have the option to use non-live scrolling. The prime example that many people use to describe this is Outlook. Scroll up and down your list of emails. You’ll notice that the view updates when you have finished scrolling, which is non-live scrolling. I did notice that when you don’t have a large set of emails it does use live scrolling.

How do I use it?

These are the new APIs added to ScrollViewer:

public class ScrollViewer : ContentControl

{

public static readonly DependencyProperty IsDeferredScrollingEnabledProperty;

public static bool GetIsDeferredScrollingEnabled(DependencyObject element) { }

public static void SetIsDeferredScrollingEnabled(DependencyObject element,

bool value) { }

public double ContentHorizontalOffset { get; }

public double ContentVerticalOffset { get; }

}

This is opt-in functionality so IsDeferredScrollingEnabled is off by default. ContentHorizontalOffset and ContentVerticalOffset are similar to HorizontalOffset and VerticalOffset except they only update their values to the new offset when the non-live scroll is completed. Also note that when turned on, it will do non-live scrolling in both the horizontal and vertical directions.

Well, that sounds easy enough. I put together a really quick sample that uses non-live scrolling and in addition adds a cell counter to let you know where you are as you scroll. This is similar to Word’s “Page: x of y” functionality.

I use a ListView and bind IsDeferredScrollingEnabled to a CheckBox so you can turn it on and off dynamically. The item counter is only visible when non-live scrolling is turned on.

<ListView Name="mylv"

ItemsSource="{Binding Mode=OneWay, Source={StaticResource products}}"

ScrollViewer.IsDeferredScrollingEnabled="{Binding ElementName=myCheckBox, Path=IsChecked}">

Note that IsDeferredScrollingEnabled is an attached property and works with ListView because a ScrollViewer is defined in the ListView's control template. The counter I'm using is bound to a property of the ScrollViewer (VerticalOffset) which I use a converter to show the correct current and total items.

Here is the project which works on the WPF 3.5 SP1 beta bits.

WPF 3.5 SP1 feature: IEditableCollectionView

vinsibal — Wed, 21 May 2008 00:00:00 GMT

Motivation

A CollectionView is your interface into manipulating a collection of data items in an ItemsControl. Common tasks with this view often involve applying sorting, filtering, and grouping. In lieu of supporting a DataGrid control, transactional adding/editing/removing is an essential feature for data manipulation and a new view has been added in WPF 3.5 SP1 to support this functionality.

What is it?

IEditableCollectionView is a new collection view that you can use to supports adding and removing new items, as well as editing items in a transactional way. It is implemented by ListCollectionView (the default view for ObservableCollection) and BindingListCollectionView (the default view for DataTable). I will go through an example to further describe it and summarize afterwards.

Background on the example

I will be creating a ListBox with some data that you can add/remove/edit each item. You also have the option to cancel in the middle of editing the item. I will use buttons to trigger an item for editing, adding, removing, etc. Here is the ListBox xaml:

</Style>

<ListBox Name="itemsList"

ItemsSource="{StaticResource products}"

ItemContainerStyle="{StaticResource listBoxDefaultStyle}"/>

When the ListBox is not in edit mode it will use a template of TextBlocks.

</StackPanel>

</DataTemplate>

When it is in edit mode, it will use a template of TextBoxes (I will set the DataTemplate dynamically in code).

</StackPanel>

</DataTemplate>

How do I use it?

Just like the other collection views, you can obtain a reference to this collection using the CollectionViewSource.GetDefaultView,

// retrieve a reference to the view

ICollectionView view = CollectionViewSource.GetDefaultView(itemsList.Items);

IEditableCollectionView iecv = (IEditableCollectionView)view;

Before I go any further, there is an important point to note about delegation of work. When the data source implements IEditableObject, the IEditableCollectionView will call BeginEdit() when a new item is added or an existing item is opened for edit. It will call CancelEdit() when the item is cancelled and EndEdit() when the item is committed. IEditableCollectionView lets the app author handle this part of the transaction.

In my data source, I will be creating a copy of the selected data item when it is opened for edit. If the procedure is cancelled, I will use the copy to reset the original state, otherwise the new data will update the data source. I’ve only included the relevant information of the data source here.

public class Product : INotifyPropertyChanged, IEditableObject

{

private Product copy;

#region IEditableObject Members

public void BeginEdit()

{

if (this.copy == null)

this.copy = new Product();

copy.Book = this.Book;

copy.Author = this.Author;

copy.Price = this.Price;

}

public void CancelEdit()

{
this.Book = copy.Book;

this.Author = copy.Author;

this.Price = copy.Price;
}

public void EndEdit()

{
copy.book = null;

copy.author = null;

copy.price = 0;
}

#endregion IEditableObject Members

}

Let’s first focus on editing items. To initiate an item to be edited you call IEditableCollectionView.EditItem(). As I just discussed, this will call BeginEdit on my selected data item. Here is the code that is called when the edit button is clicked (Notice the template of the item container is updated here):

private void edit_Click(object sender, RoutedEventArgs e)

{

// edit the item

iecv.EditItem(itemsList.SelectedItem);

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("EditingTemplate");

}

So now that the current selected item is editable, the changes to it can either be submitted or cancelled. We shall look at the submitted scenario next. To commit changes, you call IEditableCollectionView.CommmitEdit(). This will then call EndEdit() on my data item where I reset my copy of the data as it is not needed anymore. Here is the code when the submit button is clicked:

private void submit_Click(object sender, RoutedEventArgs e)

{

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

iecv.CommitEdit();

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("DefaultTemplate");

}

The cancel scenario is very similar to the submit code, but instead CancelEdit() is called on my data item where I reset it’s values to the copy that I stored from BeginEdit():

private void cancel_Click(object sender, RoutedEventArgs e)

{

// update the template

ListBoxItem lbItem = (ListBoxItem)itemsList.ItemContainerGenerator.ContainerFromItem(iecv.Current EditItem);

iecv.CancelEdit();

lbItem.ContentTemplate = (DataTemplate)this.myGrid.FindResource("DefaultTemplate");

}

Adding new items and removing items follow a similar pattern where the view will call BeginEdit, CancelEdit, and/or EndEdit on the data item. One important difference however is how it is managed for you. While I was managed part of the editing transaction, the IEditableCollectionView will managed the addition and removal of an item. When IEditableCollectionView.AddNew() is called, a new data item is actually added to the data source by the collection view. In BeginEdit, you have the option to initialize the new item to default data. Same goes when CancelNew() or Remove() is called. The item that was added or selected is actually removed from the data source by the collection view. There is no additional code that you need to write to create the new data item and manually add it to the data source. You can check out the full project attached to view the source for adding and removing as well as the editing that I talk about above. It works with the WPF 3.5 SP1 bits.

For completeness, here is the full list of APIs from IEditableCollection. I try to make use of most of them in my project.

public interface IEditableCollectionView

{

bool CanAddNew { get; }

bool CanCancelEdit { get; }

bool CanRemove { get; }

object CurrentAddItem { get; }

object CurrentEditItem { get; }

bool IsAddingNew { get; }

bool IsEditingItem { get; }

NewItemPlaceholderPosition NewItemPlaceholderPosition { get; set; }

object AddNew();

void CancelEdit();

void CancelNew();

void CommitEdit();

void CommitNew();

void EditItem(object item);

void Remove(object item);

void RemoveAt(int index);

}

New WPF 3.5 SP1 feature: Data Formatting (with Binding.StringFormat)

vinsibal — Fri, 16 May 2008 17:31:00 GMT

Background

Formatting data can be a pretty cumbersome task in WPF. To illustrate with a very simple example, let’s say I want to display the dollar value of some item in a TextBlock:

<sys:Double>168.361</sys:Double>

</ComboBoxItem>

<sys:Double>456.9832</sys:Double>

</ComboBoxItem>

</ComboBox>

<TextBlock.Text>

</TextBlock.Text>

</TextBlock>

</StackPanel>

To add in a $ symbol and/or any other formatting, I would need to write my own ValueConverter and do the formatting there.

<local:MoneyConverter x:Key="moneyConverter" />

<TextBlock.Text>

</TextBlock.Text>

</TextBlock>

public class MoneyConverter : IValueConverter

{

public object Convert(object value, Type targetType, object parameter, CultureInfo culture)

{

return string.Format("Item cost: {0:C}", value);

}

// ConvertBack left out

}

It would be nice if I could just include the formatting as a definition with my binding. It would be more readable and self-documenting, as well as decrease the number of ValueConverter classes that I would need to write (which may not be very reusable in the rest of your application). Well, as it turns out this feature has been added in WPF 3.5 SP1.

What is it?

Strings can now be formatted directly in bindings, multibindings and many controls by String.Format(IFormatProvider, String, Object[]). Note that string formatting is only applied in the direction from source to target. Anytime the source is updated, the converter/formatting will be reapplied.

Examples

Single binding standard:

<TextBlock.Text>

</TextBlock.Text>

</TextBlock>

Single binding convenience:

<TextBlock.Text>

</TextBlock.Text>

</TextBlock>

Single binding escaping markup:

<TextBlock.Text>

</TextBlock.Text>

</TextBlock>

Formatting in DisplayMemberBinding:

MultiBinding:

<TextBlock.Text>

</MultiBinding>

</TextBlock.Text>

</TextBlock>

MultiBinding with a converter (note that the converter is called before the string is formatted):

<TextBlock.Text>

</MultiBinding>

</TextBlock.Text>

</TextBlock>

Many controls have also added a new property to set format on its content. For example, ContentControl has added ContentStringFormat, HeaderedContentControl has added HeaderStringFormat, and ItemsControl has added ItemStringFormat. These are only a few examples.

<sys:DateTime>2004/3/4 13:6:55</sys:DateTime>

</Label>

<sys:DateTime>2004/3/4 13:6:55</sys:DateTime>

</Button>

<sys:Double>3.14159</sys:Double>

<sys:Double>2.71828</sys:Double>

</ListBox>

There are a lot more examples that can be shown for controls. I may do an additional post on that as it can seem a little complicated at first when dealing with controls that have multiple ways of setting format. Anyway, I hope that you may find this new feature useful. It will definitely be handy for the DataGrid.

More WPF 3.5 SP1 resources

vinsibal — Fri, 16 May 2008 05:52:00 GMT

Here are some pretty comprehensive resources on the new features in our WPF 3.5 SP1 release.

Scott Guthrie's blog post on installation issues, features in Visual Studio and the .NET framework.

Jossef Goldberg's blog post on performance improvements in WPF.

Greg Schechter's blog post on new graphics features in WPF.

I'll be posting about some more new WPF features soon. The next one I'll post will be on the new formating capabilities so stay tuned.

Recycling that Item Container

vinsibal — Thu, 15 May 2008 04:07:00 GMT

Item container recycling is a one of the many new features in SP1. I'm going to talk a little bit about it here.

What is it?

As a little background, the VirtualizingStackPanel’s virtualization scheme basically works like this: generate containers when needed and throw them away when they are no longer in view. This does solve the memory issue that is created when the panel has a large number of items, but it can still be very expensive to have to recreate and throw away containers every time they go out of view. Enter container recycling. Container recycling is a performance optimization to this virtualization scheme. It basically reuses existing containers so they do not have to be recreated each time they come back into view.

How do I use it?

VirtualizingStackPanel’s virtualization will still work the same as before. In fact container recycling will be turned off by default. I will explain how to turn it on shortly, but before that let me describe the new API. VSP (VirtualizingStackPanel) has added a new attached property, VirtualizationModeProperty, as well as the getter and setter for it, GetVirtualizationMode and SetVirtualizationMode. This property is used to describe the type of mode that it can be in, VirtualizationMode.Standard or VirtualizationMode.Recycling. The former will use the standard virtualization scheme just as it normally would and the latter will include recycling to the virtualization scheme. The VirtualizationModeProperty is to be set from the ItemsControl that hosts the items presented by the VSP. By default, it is set to VirtualizationMode.Standard.

Here is an example of turning on recycling on a ListBox:

Note that ListBox uses a VSP as its ItemsPanel and sets the VirtualizingStackPanel.IsVirtualizing attached property to true by default. If you were using ItemsControl directly or creating a custom ItemsControl that uses a VSP as its ItemsPanel, you will need to set both attached properties to get the recycling behavior.

Special considerations

Just as with the virtualization scheme, marking containers as non-virtualizable will not virtualize or recycle the container. You can do this by handling VSP’s CleanUpVirtualizedItem event. This event is fired when a container is about to be thrown away or recycled. You have the option here of cancelling the operation.

Some other helpful methods for you to have more control of the data items and containers include ItemsControl.PrepareContainerForItemOverride which is called before a container is used and ItemsControl.ClearContainerForItemOverride which is called when a container is thrown away or recycled.

For more information regarding scrolling performance take a look at this article by one our dev's here on the WPF team. It came out before this feature so the information regarding container recycling is a suggestion on how to implement it and not how to actually use it. It still has a lot of great information though.