Notes in Modern Programming

Sending messages in your application

2010-02-16T08:55:00.000-08:00

I got a question from a friend the other day that went something like this:

I have an application that has n modules, and I need to communicate between them. I have been using some messaging stuff for a while now, and as my application has gotten more complicated, it has become messy. How are you doing this?

Communication between modules in any application is always tricky, and can always get messy. Think of it this way. What if I wanted to send a text message to somebody. Only, instead of sending it to somebody, I had to hope the right person / people were expecting my message, and would act appropriately. And, conversely, i would also hope people who were not supposed to be listening were not, and didn’t do anything when I sent the message. See Twitter and it’s incredible reliability.

So how do you solve this problem? Well, the quickest way is to download a messaging framework like Courier (thanks Brad!). Now you can send messages where ever you want! Although I am not a fan of the messaging idea, I really like everything in my application to be as defined as possible. I have never really felt comfortable sending a message “SelectedItem” with the item selected attached to it as an object. I just don’t like it when I have to count on my subscriber to convert my object to the right thing (boxing and unboxing concerns aside).

My preferred way to solve this problem is to created an object who's sole responsibility is to keep track of the selected item. Then, using my favorite dependency injection framework, I would register the ItemSelector and anything that needed a reference to my item selection object could get at it. Here’s what the interface would look like:

This defines all the pieces we need for the selection, now for the implementation of the interface:

Now, any part of my code that might need to know about selection change, just needs to have a reference to the instance of ItemSelector (or, if you are using dependency injection, would just need to be injected with the IItemSelector interface). Of course, the standard cautions apply to subscribing and then UNSUBSCRIBING from events. But this should work fine, and can be expanded to fit the needs of your complexity.

PDC, Day 1

2009-11-18T13:16:00.000-08:00

Keynote

In the keynote, there was a ton of talk about Windows Azure, which wasn’t really very new from last year. Microsoft is going live with Azure starting at the beginning of this year, followed by the start of billing in February. Again, not really new stuff, but I think everything will eventually end up in the cloud. If Microsoft can continue to separate the implementation of this so I don’t have to think about which platform to target as a developer, it’s going to be a nice win.

Sessions

Future Directions of C# and Visual Basic

First, Luca is a great guy to listen to talk. I heard him once before talking about F# at a code camp and he is a fun guy to listen to. Good stuff here about languages. Really enjoyed the talk about dynamic stuff. I have to admit I have been a bit of a pessimist about the general use of var, and dynamic only took that further. This really helped me understand how the dynamic type works, was well as how the compiler treats the dynamic type. Good stuff also about how the DLR caches the use of run time binding. Also, Microsoft is toying with the notion of not only writing the compiler in their native languages, but opening up the compilers for use by you and me!

SQL Azure Database: Present and Future

One word to describe this: overwhelming. The SQL Azure team has done a great job of abstracting the implementation of this service. There is still some stuff left to be desired, but this is getting really nice. Lots of talking about low level implementations and how the SQL Azure encrypts and blocks out hacks. Kind of confusing and this pretty much fried my brain.

Sketchflow: Prototyping to the rescue

I am now a huge fan of SketchFlow. Great tool. If you are prototyping anything XAMLy, this is for you. Great new font that purposefully dumbs down the look of the application so users can focus on functionality, not why the button font isn’t Arial Bold with a Green to Blue radial gradient. Check out this session. Definitely my surprise favorite session of the day.

Unit Tests and the PrivateObject, Part 1

2009-11-04T14:15:00.000-08:00

As a developer, it’s hard to stick to writing unit tests. It’s really awesome if you do test driven development and write them first, but a lot of the times I find it hard to sick to this plan for various reasons. No, it’s not cause I don’t want to….sort of.

One of the really cool things about the unit test framework built into visual studio, is the ability to create a unit test that will test even your private methods. You can do this by right clicking in the .cs and selecting the “Create Private Accessor” option, which will then offer you the list of test projects to generate this class in. Here is the menu:

You can read more about doing this here. Now, we should be able create an instance of you new accessor in the unit test by instantiating MyObject_Accessor. In the instance of the object, you should now have access to all of the fields and methods of the original object that are not public. Sweet.

Hanging off of this accessor object, you will see a property called Target, of type Object. This holds something called a PrivateObject, which should be a wrapper around your original object, MyObject. I have been doing a ton of Dependency Injection in my projects lately using Unity to decouple my projects from eachother. Using the PrivateObject is critical to creating a mock version of my dependency injector for the purposes of unit testing.

In a follow up to this, I will post some code showing how to create a mock injector, and how to make use of the PrivateObject in that injector. Now go test!

Dynamic DataTemplates in WPF

2009-10-21T16:59:00.000-07:00

A while back, I had to do some tricky stuff with WPF. The WPF application need to have a new data type deployed to it on the fly, and then have a set of dynamic data templates deployed to the same application for that new data type. The first pass I made to accomplish this was to make myself an attached property and markup extension to funnel information into a singleton object I would use to manage all of the dynamic styles. Let me expand a little more on my design choice before going into the details.

First, I wanted to have something be in charge of managing all of my data templates. This needed to be the keeper of everything that is styles. This class should be in charge of registration of styles, as well as handing these styles out when they are asked for. Second, I would need to come up with some way of uniquely identifying these data templates, or create a key if you will. After all, we can't have duplicate templates for whatever reason. Lastly, I need some way to give all of this information to WPF so I could leverage it in my XAML. My markup would need to be able to bind to this information so it can be resolved during runtime.

So, like I was saying, my first pass involved using a markup extension in some XAML resource dictionary that would be dynamically merged into the main resource dictionary. This was mostly working fine, but I had this syntax that was bothering me quite a bit. What I essentially had was a attached property referencing my custom markup extension. The thing that got annoying was WPF was requiring me to fill in x:Key for the DataTemplate anyway, even though I wasn't using it. What was happening was my x:Key value was turning out to be the textual representation of my custom markup value. That was dumb to me because I was passing the same information twice. I tried putting my markup extension into the x:Key value, but WPF kept barfing at me when I did this. I stumbled onto this gem, which should have been much easier to find. My very own custom DataTemplateKey!!

Lets start with the new key object I created to be my unique value for each DataTemplate:

A quick summary about this. I have a name value that is a string and a instanceType value that is also a string. This should sound very familiar to you if you have used WPF. I have made sure to override the standard System.Object overrides for equality. Next, our markup extension:

Notice the base class of DataTemplateKey. This allows us to place our markup in the x:Key field of the XAML. The XAML markup will map to our key now, so we have the same fields here as strings, name and instanceType. The really important part here is the override of ProvideValue that will get called when the XAML if parsed. We are going to use our new key class to create a key. Then, we pass the key to the DynamicTemplateManager. Here is the code listing for that class:

I left out some of what I consider to be the fluff of this class for readability. First thing to notice is the DependencyObject as the base class. This helps to allow us to use our new template manager in the XAML, so we could bind to it if we wanted. Cool stuff of note are the two indexers that should aid in the binding process, particularly the string, string indexer. The key to the whole class is the Add method and the different dictionaries declared locally. The dictionaries are going to keep all of my templates keys based on how I register them. We have one each for typed templates, named templates, and typed and named templates. Now, as long as our dynamic XAML is merged in with our visual tree, and using our keys, we should be able to find our DataTemplate using a App.Current.TryFindResource(object) passing the DynamicTemplateKey as the parameter.

You can download the source code for this here. I haven’t posted any examples in it of how to use the key in XAML, but if you are familiar with DataTemplates and MarkupExtensions, it shouldn’t be a problem for you. If I get a fair about of interest in using this in an example, I may post a part 2 to this post. Please feel free to let me know if you would like to see an example.

Using SQL Full Text with LINQ

2009-10-16T08:38:00.000-07:00

Working with a database is a fairly common scenario for many business applications. You have to store that data somewhere right? It’s been a while since I have done any database work at my awesome job, so I took it upon myself to play with SQL Server a few days ago for fun. I have been getting more and more familiar with LINQ, so I chose to use some of the LINQ to SQL goodness. Let’s start with this piece of code to find some customer orders:

IQueryable<OrderEntity> orders = from order in _context.OrderEntities
where Description = "computer"
select order;

I set up LINQ statement, and it’s going to select all of my orders that have a description of computer. But what I really want is to find all of the orders with the word computer IN them. So let’s switch our statement now to use the LINQ translation of SQL contains:

IQueryable<OrderEntity> orders = from order in _context.OrderEntities
where Description.Contains("computer")
select order;

Great. Now we are searching for all of the orders that have a description containing the word computer in it. This is a great improvement over what we had before, but to be blunt, it still sucks. Why? Because everybody expects all searches to work like a Google search. If I search for computer, it should bring back all things related to computer. This is where full text search comes in. You can read more about full text search here if you would like, but the summary of it is that it does a more linguistic search instead of a black and white search. So let’s combine full text search into our LINQ statement.

……

Crap. It’s not supported by LINQ. What to do. Well, after some pondering, I realize that what I’m doing in 99% of my time with full text search is using the CONTAINSTABLE function. From a high level, CONTAINSTABLE is based on whatever search term(s) you pass in, and gives back as a result a table with the key, in this case our table primary key, and a rank of how closely the search term was able to match to the column(s) you searched against. Unfortunately, this still doesn’t really get me any further because I still can’t call this from LINQ. Hmmmm.

GOT IT! What I can do is create a table based function and call that from LINQ. So, I create a table based function called Orders_FullTextSearch and drag it into my LINQ data context. I can now update my LINQ to SQL statement:

IQueryable<OrderEntity> orders = from order in _context.OrderEntities
join fts in _context.Order_FullTextSearch("computer")
on order.Id equals fts.Key
select order;

There we go, full text searching in LINQ. You can expand on this example to use the FREETEXTTABLE as well. I purposefully glossed over the SQL implementation of this because I wanted to focus on the coding part, but you can read more the functions I mentioned here. Full text searching can be complicated to set up, but it’s really cool in action and can add some pretty nice features to any searching you might be doing in your code or database. I should also mention that it may take some type of SQL guru to optimize and administrate the full text stuff. But you can make your end user happy!

C# 4.0 and Variance

2009-08-06T18:14:00.000-07:00

Variance was a tough thing for me to figure out. I recently gave a talk on the features of C# 4.0 and this was one of the topics I covered. I’d like to start out with a common scenario I have always had trouble understanding. Take the following code snippet:

IList<object> stuff = new List<string>();

This will not compile in any existing version of the .NET framework. I have always struggled to understand why this wouldn’t work. The System.String type is certainly something that can fulfill all the requirements of the System.Object. Well, here’s why this doesn’t work. The generic List is a reference type. What this means, is that every time somebody references that object in the code, they will get a pointer to some location on the heap. It doesn’t matter how many times you use the List, you always get the same reference to the pointer, hence reference type. So, let’s expand on our previous example:

IList<object> stuff = new List<string>();
stuff.Add("Joe is awesome");
stuff.Add(9);
stuff.Add(false);

Here is where the problem lies. As far as we are concerned, the declaration of stuff is an IList<object>. This means that we can add any object to it, including an int or bool. But let’s go back to what we just established. The .NET framework is storing a reference to the underlying declaration, which is actually a List<string>. We cannot add a int or bool to this list because they are not strings. This cleared up something for me I had been wondering for a long time. Let’s elaborate on this:

IEnumerable<object> stuff = new List<string>();

Currently, just as stated before, .NET will not allow us to do this. But wait you say? It should? I would have to agree. Here’s the reason. IEnumerable is a special class. The reason it is so special is that IEnumerable doesn’t accept modifications. The only thing IEnumerable is responsible for is returning objects, or rather objects coming out. This throws a wrench into what we stated before. Here is a perfectly valid scenario where you should be able to assign this because we will not be making any internal modifications, and could therefore avoid any such typing problems stated in the previous case.

Here, IEnumerable<string> can definitely fill the role of an IEnumerable<object>, because string is said to be the more specific type and object the more generic. To put it another way, string is covariant to object. The only problem is, .NET 3.5 and earlier had no way to deal with this situation. Enter .NET 4.0. Here are a couple interface definitions:

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}
public interface IEnumerator<out T> : IEnumerator
{
    bool MoveNext();
    T Current { get; }
}

The new keyword you see, “out”, is specifying that we are only ever going to allow T to come out of our interface. This will allow our previous attempt of assigning IEnumerable<string> to IEnumberable<object> because we just told the compiler that T will never be coming in to our interface.

Of course, there is the opposite scenario as well where a type is only going into your interface. This is best demonstrated by looking at the following class:

class Program
{
    void Manipulate(object obj)
    {    
    }
    void ContravariantGoodness()
    {
        Action<object> manipulateObject = Manipulate;

        Action<string> manipulateString = Manipulate;

        manipulateString = manipulateObject;
    }
}

The only thing you don’t see here is that the Action definition in C# 4.0 contains the in keyword for the generic parameter. As stated previously, this will not work in .NET 3.5 or earlier. In this example, object is contravariant to string because it is going from a more generic type to a more specific type. Because in this case the variable coming in is an object, we can really pass anything (almost) in .NET that will fulfill that contract, including a string. Pretty cool stuff.

One major thing to remember is that this is all based around reference types. Something like can never be involved in either of the scenarios:

public struct Parent<T>
{
    public T GetT()
    {    
        ...
    }
}

I am really excited to see this in .NET 4.0, and I personally think it is the best of the new features added. Now go check it out.

Snoop 64 bit

2009-07-15T18:20:00.000-07:00

I can't really take much credit for this because I didn't do that much work for it, but here is a link to his post on 64 bit snoop. You can thank my coworker Dan for 99% of this.

If you are doing any WPF development, you NEED this tool. Dan has taken the time to throw some pretty nice additions into this version of the tool, so even if you already using snoop, you should take a look at his modified version.

Happy snooping!

Two great .NET features

2009-07-15T15:41:00.000-07:00

I always like it when I come across a nice little feature I find in the .NET Framework. If I find two in one day, it’s even better. This is exactly what happened to me yesterday. We’ll start out with the first feature, actually the only feature I intended to learn about yesterday, the yield keyword.
I use dependency injection on a lot of my projects, including implementing some type of container. Sometimes I use Unity, sometimes I roll my own. Regardless of what I use, I end up with a project full of interfaces, including IDataProvider. For the most part, I end up implementing a MockDataProvider and an XmlDataProvider. I find this case very common inside of a DataProvider method:

public IEnumerable<IStoredObject> GetStoredObjects()
{
    List<IStoredObject> objects = new List<IStoredObject>();

    foreach (XElement objectElement in XDocument.Elements("Objects"))
    (
        objects.Add(CreateStoredObject(objectElement));
    )

    return objects;
}

This always irritates me to no end because I am just creating this List<> so that I can return these values. I wish I could just return them. But alas, you can.

public IEnumerable<IStoredObject> GetStoredObjects()
{
    foreach (XElement objectElement in XDocument.Elements("Objects"))
    (
        yield return CreateStoredObject(objectElement);
    )
}

Bam. This simple statement will tell the compiler to return something it can enumerate through. There are other uses for this keyword as well, but for me, I will use this case all of the time. Here and here are articles with some more information.
Now for part 2. Coincidentally, this subject was on the next page in a book I was reading to find out about yield, which is why I found out about it. I frequently have need for the ICloneable interface. There is a well known debate in the development world about this interface. Some think ICloneable should be a deep clone, some think it should be a shallow clone. Regardless, all the way down in System.Object, is a protected method called MemberwiseClone. This does a shallow copy for you. What? Yeah, I know. I had no idea either. It will copy all of your fields in your class for you and return the object. Like everything else in .NET, if it’s a value type, you get a copy, if it’s a reference type, you get the same reference. Pretty sweet.

WPF Screen Transition

2009-07-14T16:07:00.001-07:00

One of my favorite things about WPF is the ability to use gratuitous animations in places where it would have been difficult in previous technologies. We threw in one of these animations on our last project. The project was using a Surface, but since it is just WPF, the idea is the same.
Here is the high level concept. You start out with a main window in your application. In this main window, you want to change some content. Instead of having a jumpy screen jerk, you get a nice animation from screen to screen. This could be a fade in and fade out, or it could be a slide in and slide out. It’s totally up to you as to how far you want to go. So let’s get started.
First, we have our main window.

<Window x:Class="ScreenTransition.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="The Transition Window"
Height="300"
Width="450">
<Canvas x:Name="TransitionContainer" />
</Window>

This is going to be where all of the work is done. This is all you will see in the Xaml view of your window. We are going to use the Canvas later on to add and remove UIElements from. Let’s jump to the code behind.

namespace ScreenTransition
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class MainWindow : Window
{
readonly Duration _animationDuration = new Duration(TimeSpan.FromSeconds(1.0));

DoubleAnimation CreateDoubleAnimation(double from, double to, EventHandler completedEventHandler)
{
DoubleAnimation doubleAnimation = new DoubleAnimation(from, to, _animationDuration);

if (completedEventHandler != null)
{
doubleAnimation.Completed += completedEventHandler;
}

return doubleAnimation;
}

public MainWindow()
{
InitializeComponent();
}

}
}

This is the start of our window. First, our Duration. Just to keep some consistency, we are going to make a single Duration. This way, we don’t have to keep making one, and the times will be the same to give our end user a consistent experience. The CreateDoubleAnimation method is just a helper for us. This will create the double animation and hook up to the completed event hander that we pass to it (could be an anonymous delegate…). Now, lets take a look at the two animations I chose to create as a starting point.

void FadeAnimation(UIElement newContent, UIElement oldContent, EventHandler completedEventHandler)
{
newContent.Opacity = 0;

TransitionContainer.Children.Add(newContent);

DoubleAnimation outAnimation = CreateDoubleAnimation(1, 0, null);
DoubleAnimation inAnimation = CreateDoubleAnimation(0, 1, completedEventHandler);

oldContent.BeginAnimation(UIElement.OpacityProperty, outAnimation);
newContent.BeginAnimation(UIElement.OpacityProperty, inAnimation);
}
void SlideAnimation(UIElement newContent, UIElement oldContent, EventHandler completedEventHandler)
{
double leftStart = Canvas.GetLeft(oldContent);
Canvas.SetLeft(newContent, leftStart - Width);

TransitionContainer.Children.Add(newContent);

if (double.IsNaN(leftStart))
{
leftStart = 0;
}

DoubleAnimation outAnimation = CreateDoubleAnimation(leftStart, leftStart + Width, null);
DoubleAnimation inAnimation = CreateDoubleAnimation(leftStart - Width, leftStart, completedEventHandler);

oldContent.BeginAnimation(Canvas.LeftProperty, outAnimation);
newContent.BeginAnimation(Canvas.LeftProperty, inAnimation);
}

Each of these methods are going to take two UIElements, the old element (current content) and the new element (content to be shown). The methods also take the same completed event handler so we can pass it on to our helper method we just created. The FadeAnimation is going to set the opacity of the new element to 0, add it to the TransitionContainer (our only item in our Window, remember from before?). Then, we animation our new elements opacity from 0 to 1, and the old elements opacity from 1 to 0, creating a smooth fade in / fade out effect. Cool huh? Same idea for the slide animation, except we are going to animate the Canvas.Left property of each UIElement. Only tricky part here is to make sure that the Canvas.Left property is actually set on the element, and if not, assume it is 0. Next, the publicly exposed method that our application can call to change content.

public void ChangeContent(UIElement newContent)
{
if (TransitionContainer.Children.Count == 0)
{
TransitionContainer.Children.Add(newContent);
return;
}

if (TransitionContainer.Children.Count == 1)
{
TransitionContainer.IsHitTestVisible = false;
UIElement oldContent = TransitionContainer.Children[0];

EventHandler onAnimationCompletedHandler = delegate(object sender, EventArgs e)
{
TransitionContainer.IsHitTestVisible = true;
TransitionContainer.Children.Remove(oldContent);
if (oldContent is IDisposable)
{
(oldContent as IDisposable).Dispose();
}
oldContent = null;
};

SlideAnimation(newContent, oldContent, onAnimationCompletedHandler);
//FadeAnimation(newContent, oldContent, onAnimationCompletedHandler);
}
}

First up in this method, we check if there are any items in our Container. If there are not, this is the first time into the screen and instead of a fade, we will just show the content right away. If there are more than one item, we are going to do our fade. We already went over the methods that do all of the animations, so we can ignore those calls. First, we want to make sure that our container can’t be interacted with while the content switch is happening, so we set the IsHitTestVisible to false for now. Next, we are going to assume that the TransitionContainer’s first element is the old content and store a reference for use as our old content. Next, the in line delegate. When the animation completes, we want to set IsHitTestVisible back to true. Next, we want to remove our old content. Finally, we want to call dispose on our object if it implements IDisposable, and the set it to null. After that is just the calls to our two methods. That’s it! Here is a link to some sample code.

San Diego Code Camp Part 2 – C# 4.0

2009-07-02T15:13:00.001-07:00

Thanks to all the people who attended this code camp session. Here is a link to my slide deck. And here is a link to my sample project. Please feel free to email or send me any message if you have more questions about the presentation. I am planning on posting some more detailed information about C# 4.0 features with maybe some more samples apps in the near future. Sorry it has taken so long to get this stuff up there. Thanks again!

San Diego Code Camp Part 1 – MEF and Visual Studio 2010 Plugins

2009-07-01T21:29:00.001-07:00

Thanks to all the people who attended this code camp session. Here is a link to my slide deck. And here is a link to my sample project, VisualTwitterio. Please feel free to email or send me any message if you have more questions about the presentation. I’ve been super busy getting ready for all of these talks lately so look for more posts soon. Also, if you are looking for the information on the C# 4.0 session, I should be posting that soon. Sorry it has taken so long to get this stuff up there. Thanks again!

Setting the DataContext of a Popup or MenuBase

2009-04-22T14:28:00.000-07:00

One of the great features of WPF is the concept of the visual tree. Every element we see on the screen is some where in the visual tree. It is pretty common in WPF to want to walk up this visual tree and grab some data for binding purposes. A simple RelativeSource Binding:

<Path Fill="{Binding RelativeSource={RelativeSource Mode=FindAncestor, AncestorType={x:Type Button}}, Path=Foreground}" />

This will walk up the visual tree, until if finds the first Button, and set the Path.Fill property to the Foreground property of the Button. This works great, unless you want to find visual elements that are not in the same tree, as is the case with Popup or ContextMenu(which inherits from MenuBase). These elements will not be in the same visual tree as the rest of an application so a binding like this will not work:

<ContextMenu DataContext="{Binding RelativeSource={RelativeSource Mode=FindAncestor, AncestorType={x:Type Button}}, Path=DataContext}">

Maybe a little unexpectedly, our data context will be null. However, we can get a reference to the visual element that opened the ContextMenu. The XAML for this looks like so:

<ContextMenu DataContext="{Binding RelativeSource={RelativeSource Mode=Self}, Path=PlacementTarget.DataContext}">

Be it good or bad, this only allows access to the DataContext of the PlacementTarget. But what if we have a little more complex situation? Let’s layout a hypothetical situation. Suppose we have a ListBox control that is data bound to a list of strings. For each string, we would like to have a ContextMenu that will allow us to delete the string from the list. Let’s start with this XAML:

<Window x:Class="MultiBindingList.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1"
Height="300"
Width="300">
<Grid>
<ListBox ItemsSource="{Binding Path=Items}">
<ListBox.ItemTemplate>
<DataTemplate>
<TextBlock Text="{Binding}">
<TextBlock.ContextMenu>
<ContextMenu>
<MenuItem Header="Delete" />
</ContextMenu>
</TextBlock.ContextMenu>
</TextBlock>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
</Grid>
</Window>

We have our ListBox, and we have it bound to a list of items, and we have put a ContextMenu in the ItemTemplate. So far so good. Now, let’s switch to our code behind:

public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();

Items = new ObservableCollection<string>(new string[] { "Item 1", "Item 2", "Item 3" });

RemoveItemCommand = new DelegateCommand<string>(RemoveItemCommandExecutedHandler);

DataContext = this;
}

public ObservableCollection<string> Items
{
get;
set;
}

public ICommand RemoveItemCommand
{
get;
set;
}

void RemoveItemCommandExecutedHandler(string item)
{
Items.Remove(item);
}
}

The only thing of note here is the DelegateCommand. It’s a class that implements ICommand and is frequently used in WPF to forward a command from a view to a view model. Now, in order to get the ContextMenu Command and CommandParameter property set correctly, we will have to pass in two object. The first will be whatever the ListBoxItem.DataContext property has been set to by WPF. The second will be the ICommand in the code behind, which we will get by walking the visual tree. But we can’t walk the visual tree you say? Enter the MultiValueBagConverter. First, let’s look at the code and then walk through it:

public class MultiValueBagConverter : IMultiValueConverter
{
#region IMultiValueConverter Members
public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
return new List<object>(values);
}
public object[] ConvertBack(object value, Type[] targetTypes, object parameter, System.Globalization.CultureInfo culture)
{
throw new NotImplementedException();
}
#endregion
}

Here, we are using a IMultiValueConverter to transform all of our MultiBinding values to a List<object>. This should allow us to pass in any number of parameters, and use them by calling an index on our newly created list. Let’s update our XAML with the converter, setting the correct data contexts:

<Window x:Class="MultiBindingList.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:Local="clr-namespace:MultiBindingList"
Title="Window1"
Height="300"
Width="300">
<Window.Resources>
<ResourceDictionary>
<Local:MultiValueBagConverter x:Key="MultiValueBag" />
</ResourceDictionary>
</Window.Resources>
<Grid>
<ListBox ItemsSource="{Binding Path=Items}">
<ListBox.ItemTemplate>
<DataTemplate>
<TextBlock Text="{Binding Path=[0]}">
<TextBlock.DataContext>
<MultiBinding Converter="{StaticResource MultiValueBag}">
<Binding />
<Binding Path="DataContext.RemoveItemCommand"
RelativeSource="{RelativeSource Mode=FindAncestor, AncestorType={x:Type Window}}" />
</MultiBinding>
</TextBlock.DataContext>
<TextBlock.ContextMenu>
<ContextMenu DataContext="{Binding RelativeSource={RelativeSource Mode=Self}, Path=PlacementTarget.DataContext}">
<MenuItem Header="Delete"
Command="{Binding Path=[1]}"
CommandParameter="{Binding Path=[0]}" />
</ContextMenu>
</TextBlock.ContextMenu></TextBlock>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
</Grid>
</Window>

First, we added a reference to our namespace, xmlns:Local. Second, we added a ResourceDictionary and added our converter to it, giving it a key of MultiValueBag. Hop down to the TextBlock, and we had to change our code around a bit. First, the Text property is now bound to index o of our list. Second, we set the DataContext of the TextBlock to the output of our converter, passing it in the ListBoxItem value, as well as the RemoveItemCommand we got from walking up to our Window and getting the DataContext from that. Now, our ContextMenu has it’s DataContext set to the PlacementTarget.DataContext, but now we have a list of all the items we need to execute the command. Right click to bring up the ContextMenu, push the delete menu item, an you will see the item’s disappear out of the list! Here is the source.

Background Worker, Part 3

2009-04-01T15:26:00.001-07:00

In the final post of the three part series, we are going to finish up or BackgroundMethod class. In Part 1, we covered the basics of the class. In Part 2, we started building the core of our class. In this final part, we are going to handle three things: the DoWork event, the RunWorkerCompleted event, and Unhooking our event subscriptions.

Okay, lets start with the DoWork event. What we want here is to grab our entry delegate and invoke it, passing a parameter to it if necessary.

void DoWorkHandler(object sender, DoWorkEventArgs e)
{
   try
   {
       object[] parameters = null;
       if (_parameter != null)
       {
           parameters = new object[] { _parameter };
       }
       e.Result = _entryDelegate.Method.Invoke(_entryDelegate.Target, parameters);
   }
   catch (Exception ex)
   {
       e.Result = ex;
   }

   BackgroundWorker worker = sender as BackgroundWorker;
   e.Cancel = worker.CancellationPending;
}

So, like we said before, create the parameters, and call invoke. In the event args, we are going to pass our result, if we get one. As well, if we throw an exception we will set the result of the work to the exception. Finally, we grab the background worker, check if somebody has set the work to be cancelled, and set Cancel to true if need be. In the handler for work completed, we are going to use this result to complete the processing if necessary.

void RunWorkerCompletedHandler(object sender, RunWorkerCompletedEventArgs e)
{
   if (e.Error != null)
   {
       _errorAction(e.Error);
   }
   else if (!e.Cancelled && e.Error == null)
   {
       if (e.Result is Exception)
       {
           _errorAction(e.Result as Exception);
       }
       else
       {
           if (_callbackDelegate != null)
           {
               object[] parameters = null;
               if (e.Result != null)
               {
                   parameters = new object[] { _parameter };
               }
               _callbackDelegate.Method.Invoke(_callbackDelegate.Target, parameters);
           }
       }
   }

   Dispose();
}

First, check for an error. Our error action is finally coming into play here for the exception. This way, if the background method didn’t work for some reason, pass the exception back up to the main thread so we can log it or handle it gracefully. If there was no error and the background worker hasn’t been cancelled, check for the result as an exception, calling the error action again if so.

Finally, if our method ran okay, we are going to check for a callback delegate. As previously stated, we are covering the most complex scenario in which we have a callback delegate. In more simple scenarios, you may not want to do anything we the method is completed. Here we do, so we are going to create a set or parameters, and if the DoWork handler gave us a value (our entry method could return void), we call invoke on the callback delegate.

Last, and certainly not least, we are going to call Dispose. In the dispose method somewhere, we will call this method.

void UnhookBackgroundWorker(BackgroundWorker bw)
{
   if (bw.IsBusy)
   {
       bw.CancelAsync();
   }
   bw.DoWork -= DoWorkHandler;
   bw.RunWorkerCompleted -= RunWorkerCompletedHandler;
   bw.Dispose();
   bw = null;
}

Just some cleanup here. Unhook the methods, call dispose on the background worker. And that’s it! We now have a fully reusable class that is fairly simple to use. You can find an example of the usage attached here, as well as the full BackgroundMethod class.

Talk soon.

Background Worker, Part 2

2009-04-01T15:02:00.001-07:00

In my previous post, I talked about the need to be able run a piece of work in WPF on a background thread, leaving a responsive UI in the process. I am going to start walking through how to create a reusable class that will easily allow a method to be run in the background.

The first thing I want to do is figure out how I want to use this class. I’d like to be able to pass my class a method that may or may not take a parameter to kick off the process, and may or may not return a value. Once the work has been completed, I’d like my class to call another method that also may or may not have a parameter, possibly the result of the previous method . Finally, I want to be able to handle exceptions in my code gracefully.

Let’s discuss the first requirement. This seems to fit nicely with some basics that are built into .NET. The first is the Action object. This is a Delegate for a method that has no parameters and no return value. Luckily, Action(T) is an alternate implementation of a Delegate, that allows a method that takes one parameter, T, and returns no parameters. So we have the delegates for methods that return no values. But what about methods that return values? Enter Func(TResult). This Delegate requires a method that has no parameters and returns one value, of type T. And you guessed it, there is an alternate implementation, Func(T, TResult), that allows one parameter and one return value. The combination of all of these should cover the starting method.

The second requirement is a little simpler. We want to call a method when the code is completed that may or may not have a parameter. Well, we already covered Action and Action(T) which fits perfect for this. The same goes for the exception handling, except in this case we know we are going to have an Action(Excetion), since we will presumably be handing an System.Exception.

So, looking back on the requirements, you may have noticed they all have something in common. Each of the delegates inherit from Delegate. Great! This means our references to these methods are general and only store instances of Delegate, eliminating the need for a Generic class! We can now just call Invoke on the delegate.

I’m a big fan of the factory pattern, so I’ve made a decision that my constructors should all be private, forcing the person consuming our class to call some factory methods to create my class.

Because it would take longer and we would be covering the same information, we’re not going to go through each of the cases specified above, but instead show only examples from the most complicated case. We want to run some background work on a method that takes one parameter, returns one value, and then call a method that takes that returned value as a parameter. Let’s start with the signature of the factory method.

public static BackgroundMethod Create<T, U>(Func<U, T> entryFunc, Action<T> callbackAction, Action<Exception> errorAction, T parameter)
{
   return new BackgroundMethod();
}

Should be pretty straight forward considering what we discussed. This takes three methods with various signatures, as well as the parameter for the entryMethod. We added some generic parameters here to make sure that all of the types will match when the methods are called.

Based on what we need, our class will need to store some local values. First, it will need to store all of the values passed into our method so we can access them later. Second, we need the work horse, the BackgroundWorker class.

#region Fields
BackgroundWorker _worker;
Action<Exception> _errorAction;

Delegate _entryDelegate;
Delegate _callbackDelegate;

object _parameter;
#endregion

Remember, the two Delegate declarations are storing the Func and Action since they both derive from Delegate.

Now, at construction of the class, we will want to new up our BackgroundWorker and subscribe to the events on it. As previously discussed, we will want the DoWork and RunWorkerCompleted events, as well as to allow the BackgroundWorker to be cancelled. And, to make it easier for later, we’ll add a couple overloads of our constructor.

#region Construction
private BackgroundMethod()
{
   _worker = new BackgroundWorker();
   _worker.WorkerSupportsCancellation = true;
   _worker.DoWork += DoWorkHandler;
   _worker.RunWorkerCompleted += RunWorkerCompletedHandler;
}
private BackgroundMethod(Delegate entryDelegate, Delegate callbackDelegate, Action<Exception> errorAction)
   : this(entryDelegate, callbackDelegate, errorAction, null)
{
}
private BackgroundMethod(Delegate entryDelegate, Delegate callbackDelegate, Action<Exception> errorAction, object parameter)
   : this()
{
   _entryDelegate = entryDelegate;
   _callbackDelegate = callbackDelegate;
   _errorAction = errorAction;
   _parameter = parameter;
}
#endregion

We’re making use of our original constructor in our overloads by calling this(), as well as setting some of our local values. Let’s update our static methods as well now to use our new constructor.

public static BackgroundMethod Create<T, U>(Func<U, T> entryFunc, Action<T> callbackAction, Action<Exception> errorAction, T parameter)
{
   return new BackgroundMethod(entryFunc, callbackAction, errorAction, parameter);
}

We have all the information to do the work now, but before getting into the meat of our class, let’s wrap up some ancillary items. First, a couple methods to run and cancel or work.

#region Methods
public void Run()
{
   _worker.RunWorkerAsync();
}
public void Cancel()
{
   if (!_isDisposed)
   {
       _worker.CancelAsync();
       Dispose();
   }
}
#endregion

For run, we will tell our worker to start, and for cancel, we will tell our worker to cancel. Also, we are going to implement IDisposable so there isn’t any bad stuff left hanging around when we are done with our background work. If you are not used to using this, you should get used to it.

Whew! That’s it for now. In part 3 of this series, we’re going to look at the guts of the class and finish up this object. Talk soon.

Background Worker, Part 1

2009-03-18T16:49:00.001-07:00

Many times in many projects I have worked on, there have been requirements to go out and execute some long running method. I have played with various methods of doing this before, like using IAsyncResult, with a fair amount of success. After coming across this requirement again in my current project and having been a fair amount of time since I last used this pattern, I decided to explore some of the current options for WPF.

In my research I came across and excellent CodeProject article with examples of the BackgroundWorker object version the IAsyncResult pattern. In the article is a nice sample project that shows how both of the ideas can be implemented as well. For reasons unknown even to me, I settled on the BackgroundWorker object, I guess because I have never really liked using the IAsyncResult stuff.

First, some information about the BackgroundWorker object. This object definitely relies heavily on events. If you haven’t used events or are not used to subscribing and unsubscribing from events, you may find it a bit easier to use the IAsyncResult pattern. There are two (three really, but the third is for reporting progress) events that are of major importance, DoWork and RunWorkerCompleted.

The DoWork event is where you are going to execute your long running method. This event is raised when the RunWorkerAsync method is called on the BackgroundWorker object. The DoWorkEventArgs that are passed in the event delegate an Argument you can use when starting your long running process and a Result that can be used to pass back a result of the long running method.

You will be able to access this result when the RunWorkerCompleted event is raised, immediately after the completion of the DoWork event delegates. In the parameters to the RunWorkerCompleted delegate, you will have access to result if some more processing needs to be done with it with the RunWorkerCompletedEventArgs. You will also be able to see if there was an exception thrown in the DoWork delegates, or if the an outside process has requested to cancel the operation on the BackgroundWorker by calling the CancelAsync method.

Cancelling the BackgroundWorker must be set up from the beginning by setting the WorkerSupportsCancellation boolean to “true” before calling RunWorkerAsync . The same goes for the ReportProgress method.

If you are going to be doing something like running a for loop in you long running method where you are able to report progress, you will want to make sure that you also set WorkerReportsProgress property to “true” as well. The ReportProgress method simply takes a double value that should represent the percentage of progress. The ProgressChanged delegate parameter will give you access to this percentage in the ProgressPercentage property of the ProgressChangedEventArgs.

And that's it. Wiring this up can be a little tricky. In part 2 of this series, I’ll be building a reusable class that should simplify this process a little bit. Happy codes!

SharedView and Windows 7

2009-02-05T21:54:00.001-08:00

Just as before with the SonicWall VPN Client, I needed to run a piece of software on my beta install of Windows 7. I can’t rant enough about this Windows build. It’s the first beta, and I have converted all of my computers (well, almost all, my media center pc is not working because of a faulty HDMI port on my TV, but I digress) to running it. One of the first tools I install on a clean dev machine is SharedView. It’s an amazing tool that allows collaboration on a project when working remotely. It’s super light weight, but has all of the essentials. I couldn’t work remotely without it. Unfortunately, upon running the install, it tells me I have an incompatible operating system. Says who? Well, I was at a brick wall until today. A fabulous coworker of mine reminded me of a tool to modify an MSI called Orca I used a while back. So I opened up the SharedView MSI and found a ton of hardcoded references to Vista, so I got rid of them. Installs fine, and so far no crashes. Here it is.

SonicWall Global VPN on Windows 7

2009-02-05T14:10:00.001-08:00

I love Windows 7. I’ve been using it for a couple of weeks now as my primary OS, and recently formatted ALL of my computer to it. It’s awesome. I haven’t been able to use my SonicWall VPN client though. After coming the forums, I found a solution (use at your own risk though).

1) Open Command Prompt
2) Type "Set DEVMGR_SHOW_NONPRESENT_DEVICES=1", Enter
3) Type "devmgmt.msc" to open the device manager, Enter
4) In the menu, go to View -> Show Hidden Devices
5) Expand the Non-Plug and Play node (expanded by default)
6) Right click on the SonicWall IPSec Driver, Properties, Go to Drivers Tab
7) Set Startup Type to Automatic
8) Click OK
9) Reboot and enjoy

Optionally, you may want to also set the DEVMGR_SHOW_NONPRESENT_DEVICES=0 after you are done, but it’s beta anyway right?

Using modern code standards

2009-01-30T10:45:00.001-08:00

I would like to touch on two things. Both of these things drive me absolutely insane because I enjoy reading nice code. Well written code should be really easy to understand at a high level. It should be clear and concise. These two things take away from it.

The first is abbreviating variable names. Some people like to give me a load of crap for my naming conventions. It would not be uncommon for you to find this in my code:

bool isIndicatorLightTurnOnDuringExecution = DetermineIndicatorLightStateDuringExecution();

Some people would argue that this is wrong because of having to type so much, but let me tell you what's right. I know exactly what this variable is holding, and what this method is doing. I am extremely diligent and naming my variables and methods for EXACTLY what they do. Why don't I use abbreviations or chop out some words? Because, I want to know what is going on in my code, and there isn't a chance in hell of me writing a comment without somebody making me. And can you tell me what this means:

bool isLightOn = CheckLight();

Sort of. There's a light there. But that's all I can tell you. Yeah, I can go dig through the code, but who the hell wants to do that. This may have taken me a little less time to write, but that time savings is going to be lost when I come back through when my code breaks (WHAT?) and try to figure out what is going on. This is just laziness. Or how about his one:

bool isIndLgtTrnOnDurExe = DetIndLghtSteDurExe();

Now, I have no idea what this means. I would argue that it probably takes less time to write the long form of this code than the abbreviate version of it, because I have to stop and try to figure out which letters to leave out and which to keep in. Also, am I coding in assembly language? Not last time I checked. That name is not taking up more or less space, so who care about shorting it. I wouldn't do it, ever. Take the time to write it out, and you'll be happier when you do.

The second thing that drives me nuts in the creation of the var in .NET 3.5. I hate using it. I hate seeing it. I hope it dies and goes away. Why? I am not gaining anything from it. Is it really hard to type out bool? Nope. Is it hard to type out ObservableCollection<objecct>? Maybe it used to be, but with intellisense, I don't type all of any word anyway, I hit only the first three or four keys and then move on. The thing that I lose with var is the ability to easily see what my variable is. Take this:

var item = DoSomething();
var otherItem = DoSomethingElse();

return item.Equals(otherItem);

What is this doing? I have no idea. I now have to go look at the implementation of DoSomething() and DoSomethingElse() to figure it out. Totally unreadable. I hope the decision is made to eventually get rid of var.

Code Camp Part 2 – Mesh enabled Silverlight application

2009-01-26T16:18:00.001-08:00

Thanks to everybody who came out to my code camp presentation. Here is a link to the sample Silverlight application I used. The project has the required assemblies in it already but unfortunately you won’t be able to use it without a magical key from MS. Here is my previous post for the information on the WPF application I spoke about towards the end of the presentation.

Check back on my blog within then next week, I should be posting a synopsis of the MESH and how it works, including where the Mesh enabled Silverlight applications fit in. If you have any more questions about the material, or any questions in general, let me know and I’ll answer them as soon as I can. Again, thanks for coming out.

Code Camp Part 1 – Using Live Services API

2009-01-25T11:26:00.001-08:00

Thanks to everybody who came out to my code camp presentation. Here is a link to the sample WPF project I used. The project has the required assemblies in it already but unfortunately you won’t be able to use it without a magical key from MS.

Check back on my blog within then next week, I should be posting a synopsis of the MESH and how it works, including where the Live Services API fits in. If you have any more questions about the material, or any questions in general, let me know and I’ll answer them as soon as I can. Again, thanks for coming out.

WPF Showdown - AppDomain.CurrentDomain.SetThreadPrincipal vs Thread.CurrentPrincipal

2008-12-17T15:06:00.000-08:00

Coming from the background of writing applications to support a business, I have become very familiar with the concept of logging in and the security around logging in. I have been pushed deep into the world of WPF and visualization lately, so security and logging in has been lost to the depths of my mind. A requirement came up a few weeks ago on my current project to mock up a login screen, and plan for it to work in the future. I dug around in my brain and decided to go with a familiar method of logging in, utilizing the System.Threading.Principal and the concepts surrounding it.

Since we spend most of our time here at IK working on prototypes and very new versions of software, this is not a super common scenario. The IPrincipal and IIdentity have come far since the original release of .NET, including the addition of GenericIdentity and GenericPrincipal that allow semi-custom security, without having to buff out a your own implementation of of these interfaces. Anyway, for those of you not familiar with the concept, the basic idea is you give this "token" to the application, and you access it via the Thread.CurrentPrincipal. There are other specific situations, ActiveDirectory included as well as custom built that are a little more complicated, but the premise is the same in the end.

So I set off on my merry way to do just this. I used the GenericPrincipal and the GenericIdentity and set the Thread.CurrentPrincipal on login. Fine. One of the main purposed of using the IIdentity is the .IsInRole() method hanging off of it. This was my main reason for using it in the application, I needed some role based security. I put a couple lines in my code as follows:

// blah blah

if (CurrentThread.CurrentPrincipal.Identity.IsInRole("Role1"))
{
// Do one thing
}
if (CurrentThread.CurrentPrincipal.Identity.IsInRole("Role2"))
{
// Do another thing
}

// continue blah blah

Pretty straight forward for the pattern. Then I created a basic form with the following code at the heart of it:

void DoLogin()
{
IPrincipal principal = null;

// Create new principal based on needs

Thread.CurrentPrincipal = principal;
}

Again, standard concepts here. I execute my login logic, create my IPrincipal based on the logic, then set the Thread.CurrentPrincipal to my newly created IPrincipal.

FALSE! Due to some security features of WPF, noted here, this is not allowed. Whenever I made the subsequent call to Thread.CurrentPrincipal, it was never set. I followed the article fairly well, and decided to continue with the suggestion, using AppDomain.SetThreadPrincipal.

This worked sort of as expected. When I made my subsequent call to Thread.CurrentPrincipal, it was definitely set to the correct value. Everything was going well until I tried to call logout:

void DoLogout()
{
AppDomain.CurrentDomain.SetThreadPrincipal(new GenericPrincipal(new GenericIdentity("Anonymous"), null));
}

I get this big ugly exception telling me I can't call this method twice. Are you kidding me?? Pretty standard stuff to be able to login / logout of an application for different rights. I was pretty upset at this point, and tried hacking around a bit for a solution. Since I wasn't able to find one, I ended up implementing a static ApplicationContext class, which happened to have a Principal property hanging off of it. I suppose this solution work as I wanted it to. If I was writing an application from the ground up, which I knew had to target multiple platforms, I probably would have done this anyway (Web, Windows Form, WPF, etc.) since it provides a little more control. Still a little disappointing to find the previous pattern I used is no longer a viable solution.

All things are not Equals()

2008-10-27T11:36:00.000-07:00

It seems like something so simple to do, that it often gets overlooked. The Equals() method that has been hanging off of System.Object since the beginning of (.NET) time, so hopefully most are familiar with it by now. Start by creating a stub for the method.

public class Person
{
 string _firstName;
 string _lastName;

 public string FirstName
 {
     get
     {
         return _firstName;
     }
     set
     {
         _firstName = value;
     }
 }
 public string LastName
 {
     get
     {
         return _lastName;
     }
     set
     {
         _lastName = value;
     }
 }

 public override bool Equals(object obj)
 {
     return false;
 }
}

Before we begin to try and figure out what makes one instance of an object equal to another instance of an object, we need to figure out what makes two objects of any type equal. The most likely answer is nothing, unless there is some base classes or other complex inheritance schemes going. Let's code for that by making an overload of Equals that takes a concrete object, in this case a Person, instead of a generalized object.

public override bool Equals(object obj)
{
 return false;
}

public bool Equals(Person person)
{
 return false;
}

Now we have two methods that will have two distinct jobs. The first, overridden from System.Object, is just going to make sure we have a valid Person, and nothing more.

public override bool Equals(object obj)
{
 if (obj == null || GetType() != obj.GetType())
 {
     return false;
 }

 return Equals((Person)obj);
}

Pretty simple code here. Make sure object isn't null and make sure GetType() matches our GetType(). This is going to eliminate any null reference exceptions and any type cast exceptions, two of my most hated exceptions. Now to actually check if our objects are equal.

public bool Equals(Person person)
{
 if (person != null)
 {
     return _firstName.Equals(person._firstName) && _lastName.Equals(person._lastName);
 }
 return false;
}

This code is again checking for null to make sure we don't have any null reference exceptions. After that, we finally get to what the method is supposed to do, check if two objects are equal. I chose a simple example here, check first name and last name, but the point is easily illustrated. Whatever makes an object equal to another object gets checked here, and the result returned. We're done. But wait. Not so fast. The often overlooked, but equally (no pun intended) important override should done as well.

public override int GetHashCode()
{
 return _firstName.GetHashCode() ^ _lastName.GetHashCode();
}

Why is this important? First, GetHashCode() is supposed to be unique for different objects, and the return the same value for identical objects. So, if we are overriding Equals(), or in other words, telling the framework what makes our object equal to another object, it's only proper to override GetHashCode(). Second, this code block would not execute as we think.

Hashtable table = new Hashtable();

Person person1 = new Person();
person1.FirstName = "Joe";
person1.LastName = "Seymour";

Person person2 = new Person();
person2.FirstName = "Joe";
person2.LastName = "Seymour";

table[person1] = person1;
table[person2] = person2;

What should happen here, assuming that if first name and last name are equal, which they are, Equals() will return true so there should only be one person in this hash table, but there would be two. Of course, our code will work correctly since we overrode GetHashCode(). Read more about GetHashCode() here.

Now we're done. Also, if you want to override the equals operator, all you have to do is call your Equals() method.

Binding to a Collection that doesn't allow Binding

2008-10-16T07:49:00.001-07:00

Recently, I decided to give the DataGrid in the new WPFToolkit a try in a project for a client. Our client was looking for reordering columns, sorting columns, and some other features that the DataGrid takes care of pretty nicely out of the box. One of the shortcomings that came up was the fact that the DataGrid doesn't natively support binding to its Columns property. I'm not sure the reasoning for this, but it turned out to be a pretty big gap for us, as we needed to pull the list of columns from a data store that would allow the user to drag around the columns, allowing the user to create a custom view they could save. We could have handled this in code, calling the .Add() and .Remove() methods on the Columns property, but wouldn't have fit into our MV-V-M (read more here and here) pattern very well, since we try to keep as little code as possible in the view (hopefully none!). We decided to accomplish this by extending the DataGrid to have a property we could bind to, allowing us to support the pattern.

First step was to create a new control called BindableColumnsDataGrid to extend the functionality of the DataGrid.

namespace BindableDataGrid.Controls
{
public class BindableColumnsDataGrid : DataGrid
{
}
}

Then, using a DependencyProperty, we created a BindableColumns property what will us to bind to a ObservableCollection<DataGridColumn>.

        #region BindableColumns DP
    public static readonly DependencyProperty BindableColumnsProperty = DependencyProperty.Register(
        "BindableColumns",
        typeof(ObservableCollection<DataGridColumn>),
        typeof(BindableColumnsDataGrid),
        new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, OnBindableColumnsPropertyChangedHandler)
        );

    public static void SetBindableColumns(UIElement element, ObservableCollection<DataGridColumn> columns)
    {
        element.SetValue(BindableColumnsProperty, columns);
    }
    public static ObservableCollection<DataGridColumn> GetBindableColumns(UIElement element)
    {
        return (ObservableCollection<DataGridColumn>)element.GetValue(BindableColumnsProperty);
    }

    public ObservableCollection<DataGridColumn> BindableColumns
    {
        get
        {
            return GetBindableColumns(this);
        }
        set
        {
            SetBindableColumns(this, value);
        }
    }

    static void OnBindableColumnsPropertyChangedHandler(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // TODO: Handle changing
    }
    #endregion

A couple of things to note in the DependencyProperty. First, we set this property to bind two ways by default. We want to make sure that if we make any underlying changes in the code, it will get published back out to the source. Second, we create a PropertyChangedHandler. We want to make sure we can hook up to some of the events that will be occurring in BindableColumns, mainly the CollectionChanged event in the ObservableCollection<>, so we need a spot to hook up to that. The place to take care of this is in the PropertyChangedHandler.

        static void OnBindableColumnsPropertyChangedHandler(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        BindableColumnsDataGrid grid = d as BindableColumnsDataGrid;
            if (e.OldValue != null)

        {
            ObservableCollection<DataGridColumn> oldColumns = e.OldValue as ObservableCollection<DataGridColumn>;
            oldColumns.CollectionChanged -= grid.ColumnsCollectionChangedHandler;
        }

        grid.Columns.Clear();

        if (e.NewValue != null)
        {
            ObservableCollection<DataGridColumn> newColumns = e.NewValue as ObservableCollection<DataGridColumn>;

            foreach (DataGridColumn column in newColumns)
            {
                grid.Columns.Add(column);
            }
            newColumns.CollectionChanged += grid.ColumnsCollectionChangedHandler;
        }
    
    }

The most interesting part of the work here, clearing out all of the current columns in the Columns property and adding all of the BindableColumns to the DataGrid. This takes care of the main functionality of the control.

As stated before, we are going to be interested in the CollectionChanged event. We are hooking up to it here, as well as unhooking from it if the binding source is changed. Now for the collection changed handler.

void ColumnsCollectionChangedHandler(object sender, NotifyCollectionChangedEventArgs e)
{
if (e.OldItems != null)
{
    foreach (DataGridColumn oldItem in e.OldItems)
    {
        Columns.Remove(oldItem);
    }
}
if (e.NewItems != null)
{
    foreach (DataGridColumn newItem in e.NewItems)
    {
        Columns.Add(newItem);
    }
}
}

Nothing super new here. Looking for a change in the columns, and handling it accordingly. Remove all the old items, add in all the new items. That takes care of the case where the binding source has Add and Remove called on it (via the ObservableCollection<>).

public BindableColumnsDataGrid()
{
AutoGenerateColumns = false;
}

Simple constructor. We just want to make sure that we set the AutoGenerateColumns property to false from the base DataGrid. We don't want to generate columns because we won't be using them at all.

BONUS

Another pretty cool feature we had to support was column reordering, which, as stated before, the DataGrid natively supports. However, the BindableColumns doesn't get any of this information natively, so we were not able to save this back out to our data store. Here is the code updates for taking care of that.

static void OnBindableColumnsPropertyChangedHandler(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
BindableColumnsDataGrid grid = d as BindableColumnsDataGrid;
if (!grid._syncronizingBindings)
{
    if (e.OldValue != null)
    {
        ObservableCollection<DataGridColumn> oldColumns = e.OldValue as ObservableCollection<DataGridColumn>;
        oldColumns.CollectionChanged -= grid.ColumnsCollectionChangedHandler;
    }

    grid.Columns.Clear();

    if (e.NewValue != null)
    {
        ObservableCollection<DataGridColumn> newColumns = e.NewValue as ObservableCollection<DataGridColumn>;

        foreach (DataGridColumn column in newColumns)
        {
            grid.Columns.Add(column);
        }
        newColumns.CollectionChanged += grid.ColumnsCollectionChangedHandler;
    }
}
}

bool _syncronizingBindings = false;
public BindableColumnsDataGrid()
{
AutoGenerateColumns = false;
    ColumnReordered += new EventHandler<DataGridColumnEventArgs>(BindableColumnsDataGrid_ColumnReordered);
}

void BindableColumnsDataGrid_ColumnReordered(object sender, DataGridColumnEventArgs e)
{
_syncronizingBindings = true;
BindableColumns = Columns;
_syncronizingBindings = false;
}

First, hook up in the constructor to the ColumnReordered event. Second, leveraging the fact that we decided to make the binding two way by default, in the event handler for the column reorder, we are going to set the columns back in the other direction, setting BindableColumns to the Columns which should be persisted back to our source collection. Third, we were tripped up by some binding code. It seems that when the binding is passed back the other direction, WPF doesn't seem to know we are going back in the other direction, so it tries to turn around and set our binding the other direction, creating a cycle. Adding a _syncronizingBindings flag takes care of this, by simply bypassing the normal PropertyChangedHandler if we see the columns are currently being synchronized. That's it, just slap our new BindableColumnsDataGrid into some Xaml, bind to the BindableColumns property and away it goes.