ligAZ blogs

Transpose or just rows as columns

Stefan Dobrev — Mon, 16 Feb 2009 00:17:54 -0800

A common scenario when displaying tabular data is to flip the axis so your rows becomes columns and vice versa. This can be easily achieved when you know the shape of your data. For example imagine we have a Customer class with 3 properties: Name, Age and JobCode. Let’s say that we have 5 customers in our data repository. If we want to select just the names we can do something like this:

IList<Customer> customers = Customer.GetAll();
var names =
    new
        {
            Customer1 = customers[0].Name,
            Customer2 = customers[1].Name,
            Customer3 = customers[2].Name,
            Customer4 = customers[3].Name,
            Customer5 = customers[4].Name
        };

Imagine that another Customer is added and suddenly this code have to changed. Obviously this won’t scale even in a short period of time. So what is the solution?

Introducing Transpose<T> extension method

Transpose is an operation used in linear algebra to transpose (of course) a matrix. In our case Transpose is an extension method with the following signature:

public static IEnumerable Transpose<T>(this IEnumerable<T> source)

But what did Transpose do under the covers? Here are the recipe ingredients:

1 tablespoon of DynamicClass.
2 tablespoons of Reflection.
1 cup of Expression Trees.
1 slice of LINQ.
2 slices of functional programming.

Here is the code itself:

public static class EnumerableExtension
{
    private static readonly MethodInfo GetValueMethod =
        (from m in typeof(PropertyInfo).GetMethods()
        where m.Name == "GetValue" && !m.IsAbstract
        select m).First();
 
    private static readonly ConstantExpression NullObjectArrayExpression =
        Expression.Constant(null, typeof(object[]));
 
    public static IEnumerable Transpose<T>(this IEnumerable<T> source)
    {
        if (source == null)
        {
            throw new ArgumentNullException("source");
        }
 
        return TransposeCore(source);
    }
 
    private static Delegate CreateSelectorFunc<T>(IEnumerable<T> source)
    {
        T[] list = source.ToArray();
        DynamicProperty[] dynamicProperties =
            list.Select(i => new DynamicProperty(i.ToString(), typeof(object))).ToArray();
 
        Type transposedType = ClassFactory.Instance.GetDynamicClass(dynamicProperties);
 
        ParameterExpression propParam = Expression.Parameter(typeof(PropertyInfo), "prop");
 
        var bindings = new MemberBinding[list.Length];
        for (int i = 0; i < list.Length; i++)
        {
            MethodCallExpression getter =
                Expression.Call(
                    propParam,
                    GetValueMethod,
                    Expression.Constant(list[i]),
                    NullObjectArrayExpression
                    );
 
            bindings[i] = Expression.Bind(transposedType.GetProperty(dynamicProperties[i].Name), getter);
        }
 
        LambdaExpression selector =
            Expression.Lambda(
                Expression.MemberInit(
                    Expression.New(transposedType),
                    bindings),
                propParam);
 
        return selector.Compile();
    }
 
    private static IEnumerable TransposeCore<T>(IEnumerable<T> source)
    {
        List<PropertyInfo> properties = typeof(T).GetProperties().ToList();
        Delegate selector = CreateSelectorFunc(source);
 
        foreach (PropertyInfo property in properties)
        {
            yield return selector.DynamicInvoke(property);
        }
    }
}

Note that some iterator best guidelines are also in place. And the final result is:

You can download the code from here

Have fun.

IntelliSense for Expression Blend

sdobrev — Sun, 03 Aug 2008 18:55:43 -0700

[Update]: You can find the addin for Expression Blend 2.0 SP1 here.

The problem

Expression Blend has been out in the wild for quite some time. However one of the most annoying thing was the lack of autocompletion (aka IntelliSense). Most of devs/designers out there were constantly switching from Blend to VS and backwards to do their stuff. The great free tool Kaxaml is at great help as well.

The solution

Using the Blend 2.5 add-ins architecture I have created an add-in that adds IntelliSense in Blend. I have reused the code from Kaxaml and adapted it work within Blend. Take a look:

Download

You can download the add-in from here. What you need to do is:

Extract the contents of installation archive in your Blend 2.5 installation folder (typically %ProgramFiles%\Microsoft Expression\Blend 2.5 June 2008 Preview)
Run Blend from the Blend.bat file that was extracted into Blend's installation folder. (The only way to run an add-in in Blend is to use a command line argument: -addin:path_to_the_addin - in our case -addin:Addins\Expression.Blend.IntelliSense.dll. You can also create a shortcut to Blend and pass this argument.)

Limitations

There are some limitation of the current implementation:

You should have Blend 2.5 June Preview (Version 2.1.1535) - available for free download here. For version compatible with Blend 2.0 check here.
No support for custom namespace types and custom attached properties.
Currently the Silverlight support is not accurate, because it is using the WPF XML schema for IntelliSense information.

[ReSharper] Directory name donates namespace Yes or No ?

sdobrev — Fri, 04 Jul 2008 04:05:49 -0700

If you like us are passionate user of ReSharper you know that ReSharper "did not like" when a class' namespace did not correspond to the directory structure the file belongs to. To illustrate this lets look at a simple example.

Imagine that we have a project named MyProject. By default its namespace is MyProject. Lets have a folder named MyControls in the project as well. Now lets add a class file in that folder, naming it "MyControl.cs". The default namespace that will be generated for the class will be MyProject.MyControls. It is constructed using the default namespace and joining it with the folder name. But if we change the namespace to be only MyProject, ReSharper will warn us with:

However, sometimes we may not want this behavior. We may just want to have a folder, which name will not participate in the default class' namespace. How to achieve this? Just in two easy steps:

1. Right click on the folder and choose properties.

2. Change the Namespace Provider combo box value from True to False.

Now ReSharper will be happy and everything will be fine. Peace.

Tip of the Day: Clear your ClickOnce application store

sdobrev — Tue, 24 Jun 2008 00:27:36 -0700

ClickOnce is a great technology that blurs the line between web and client(windows) applications. You can use it to easily deploy windows forms and WPF (through XBAP) app's. However there is common problem with it. The application store (the place where all ClickOnce applications get stored) has the ability to corrupt it self ending in an appropriate version mix of your application. You can end up in situation where "it works on my machine", but in reality the application did not work correctly. To avoid such situation it is a good practice to clear your application store before testing the deployment locally on your machine. You can do that using a magic (I mean it for real) command. Open Visual Studio command prompt and type:

mage -cc

And a magic happens ;)

WPF Series: IFrameworkElement - the missing interface

sdobrev — Tue, 10 Jun 2008 02:51:51 -0700

If you are familiar with WPF you are aware that the the grand daddy of all controls is FrameworkElement. It is defined in the PresentationFramework.dll assembly and derives from UIElement (defined in PresentationCore.dll). Its purpose is to serve as a base element for all framework related stuff: styles, inheritance context, etc. However there is another framework element - FrameworkContentElement. The main distinct between them is that the later did not defines its own rendering behavior (its inheritors should do so). This is way properties like: (Actual)Width or (Actual)Height are not present at FrameworkContentElement. If you examine the classes that derive from FrameworkContentElement you will find out that they are mainly text and document related ones.

So, what's the deal?

Looking through the MSDN documentation you will find out that: "FrameworkContentElement deliberately parallels many of the same APIs as FrameworkElement." However they did not implement a common interface. For example if you want to access the DataContext property (present at both classes) you should check explicitly for each type like this:

var dataContect = "DataContext";
var frameworkElement = sender as FrameworkElement;
if ( frameworkElement != null )
{
    frameworkElement.DataContext = dataContect;
}
else
{
    var frameworkContentElement = sender as FrameworkContentElement;
    if ( frameworkContentElement != null )
    {
        frameworkContentElement.DataContext = dataContect;
    }
}

This is not good and pretty as it should be. Let's fix it. Introducing the IFrameworkElement - the missing interface.

IFrameworkElement

IFrameworkElement interface contains all matching members from FrameworkElement and FrameworkContentElement. It also implements IFrameworkInputElement and ISupportInitialize, which both classes implement as well. The way to work with it is to call an extension method (AsFrameworkElement()) defined for a DependencyObject that will return the type as IFrameworkElement if the target is FrameworkElement or FrameworkContentElement, otherwise it will return null. Here is now you can operate with it:

// sender is DependencyObject
var dataContext = "DataContext";
IFrameworkElement frameworkElement = sender.AsFrameworkElement();
if (frameworkElement != null)
{
    frameworkElement.DataContext = dataContect;
}

Why DependencyObject as target?

If you wonder why the method is defined on DependencyObject - simply because this is the common ancestor of both classes.

How is it implemented?

Internally there are two wrappers that wrap FrameworkElement and FrameworkContentElement and implement IFrameworkElement. All the calls to the interface are send to the wrapped element. The actual code is very simple, but about 624 lines long for each element. (It will be a much simpler one line implementation in a dynamic language - C# 4.0 is coming :) ).

You can find a sample solution here. The code can be found on CodePlex too.

Have fun.

WPF Series: Creating Generic Adorner

Stefan Dobrev — Thu, 22 May 2008 03:35:56 -0700

As I have mentioned at the end of the previous post today I will show you how to create a generic adorner, which will allow you to decorate a single element multiple times at different positions. At the end we will be able to create something that looks like this:

To achieve this we will need a way to say that we want to position the adorner at the different corners of the element as well as to specify whether we want to be inside or outside (vertically or horizontally) of the element. Let's create some enumeration types that will serve for this purpose. Introducing AdornerPosition and AdornerPlacement enums.

AdornerPosition

public enum AdornerPosition
{
    Unspecified = 0,
    TopLeft = 1,
    TopCenter = 2,
    TopRight = 3,
    MiddleLeft = 4,
    MiddleCenter = 5,
    MiddleRight = 6,
    BottomLeft = 7,
    BottomCenter = 8,
    BottomRight = 9
}

AdornerPlacement

public enum AdornerPlacement
{
    Unspecified = 0,
    In = 1,
    OutHorizontally = 2,
    OutVertically = 3
}

Each of the enums' values speak for it self, but for clarity here is a diagram that illustrates them:

The final piece is to implement the ArrangeOverride() method of the Adorner class. It looks like this:

protected override Size ArrangeOverride( Size finalSize )
{
    if ( adorningElement != null )
    {
        Point adorningPoint = new Point();
        int pos = (int) position - 1;
 
        Rect adorneredElementRect = VisualTreeHelper.GetContentBounds( AdornedElement );
        Rect adorningElementRect = VisualTreeHelper.GetContentBounds( adorningElement );
 
        adorningPoint.X = ( ( ( pos % 3 ) / 2d ) * adorneredElementRect.Width )
                          - ( ( ( pos % 3 ) / 2d ) * adorningElementRect.Width );
        adorningPoint.Y = ( ( ( pos / 3 ) / 2d ) * adorneredElementRect.Height )
                          - ( ( ( pos / 3 ) / 2d ) * adorningElementRect.Height );
        if ( placement == AdornerPlacement.OutHorizontally )
        {
            switch ( pos % 3 )
            {
                default :
                case 1 :
                {
                    //center column do nothing
                    break;
                }
                case 0 :
                {
                    adorningPoint.X -= adorningElementRect.Width;
                    break;
                }
                case 2 :
                {
                    adorningPoint.X += adorningElementRect.Width;
                    break;
                }
            }
        }
        else if ( placement == AdornerPlacement.OutVertically )
        {
            switch ( pos / 3 )
            {
                default :
                case 1 :
                {
                    //center row do nothing
                    break;
                }
                case 0 :
                {
                    adorningPoint.Y -= adorningElementRect.Height;
                    break;
                }
                case 2 :
                {
                    adorningPoint.Y += adorningElementRect.Height;
                    break;
                }
            }
        }
 
        adorningElement.Arrange( new Rect( adorningPoint, adorningElement.DesiredSize ) );
    }
    return finalSize;
}

That's it. You can now adorn your elements passing different positions and placements. Sample project can be downloaded from here.

Have fun adorning your elements.

WPF Series: Adorners, Commands and Logical Tree

Stefan Dobrev — Tue, 15 Apr 2008 23:04:40 -0700

Today I'm going to tell you a WPF story. But before I start to dig deeper let me first introduce you the main characters in this post. Here they are:

Adorner - adorners are simple UIElement decorators. Suppose that you have a RichTextBox and you want to place a comment box over it, so that users can comment on the text in the box. This can be archived with adorners. Actually the WPF framework uses adorners internally for exactly the same purpose when you edit and annotate FlowDocument in a DocumentViewer. This is the reason why adorners are in System.Windows.Documents namespace.
Command - commands are UI flavored implementation of the command pattern in WPF. You can read about them here.
Logical Tree - There are two control trees in WPF. One is the visual one, the other is the logical one. Imagine a Button for example. The button as logical entity act as a single control, you can click on it etc. However the visual representation of the button contains different UIElements - borders, TextBlock, etc. This means that WPF should maintain two separate control trees, one for the behavior elements - logical tree and one for the visual representation - visual tree. More info here.

There are a bunch of WPF adorners samples out there (including the SDK ones as well). But as usual when you try to create something more complex the standard samples break down. For example let say that we want to achieve something like the mini toolbar in Word 2007:

Let's start our quest with a TextBox that look like this:

and you want to put a simple button next to it that will let say will open a hyperlink that is somehow related to the TextBox. You could easily achieve this with adorners and end up with something which look like this:

How to do this? You could create something like TextBoxAdorner that will derive from Adorner and will look like this:

public class TextBoxAdorner : Adorner
{
    private readonly UIElement adorningElement;
 
    public TextBoxAdorner(TextBox textBox, UIElement adorningElement ) : base( textBox )
    {
        this.adorningElement = adorningElement;
 
        if (adorningElement != null)
        {
            AddVisualChild(adorningElement);
        }
    }
 
    protected override int VisualChildrenCount
    {
        get { return adorningElement == null ? 0 : 1; }
    }
 
    protected override Size ArrangeOverride(Size finalSize)
    {
        if (adorningElement != null)
        {
            Point adorningPoint = new Point();
 
            //position at the end of the text box
            adorningPoint.X = ((TextBox)AdornedElement).ActualWidth;
 
            //position above the text box
            adorningPoint.Y -= adorningElement.DesiredSize.Height;
 
            adorningElement.Arrange( new Rect( adorningPoint, adorningElement.DesiredSize ) );
        }
        return finalSize;
    }
 
    protected override Visual GetVisualChild(int index)
    {
        if (index == 0 && adorningElement != null)
        {
            return adorningElement;
        }
        return base.GetVisualChild(index);
    }
}

Note that we call AddVisualChild() method so that the element that is passed to the constructor will be visible. It is also necessary VisualChildrenCount to return count of 1 and GetVisualChild() to return the UIElement that is added to the visual tree - in our case this is the adorningElement.

So far so good. Now imagine that the button that is added as adorner did not have a click handler, but have a command set. Let's name the command - "NavigateToLink". The command handler is added to TextBox's input bindings, because the TextBox itself "knows" how to execute "NavigateToLink" command. (The sample is with TextBox, but you could imagine have your own custom control that have that logic in it). But what happens when we do this:

As you can see the button is disabled, because the command infrastructure in WPF did not manage to find a handler for our "NavigateToLink" command. This causes the Button to become disabled. Now what?

If you refer to the command readings in the links that were in the beginning of the post you will find our that the command mechanism in WPF uses the logical tree of controls to find handlers for particular commands. This bring us to point where we added the Button to visual tree. In our case we will have to add it as a logical child of the TextBox as well. This will automatically add it the logical tree of controls and the command handler will be correctly resolved and the Button enabled. Here is the new constructor of TextBoxAdorner class:

public TextBoxAdorner(TextBox textBox, UIElement adorningElement ) : base( textBox )
{
    this.adorningElement = adorningElement;
 
    if (adorningElement != null)
    {
        AddVisualChild(adorningElement);
        textBox.AddLogicalChild( adorningElement );
    }
}

Here comes the other problem. For encapsulation reasons the AddLogicalChild() method of FrameworkElement is marked as protected internal and can not be called as we call it in the snippet above. One way to workaround this is to derive from TextBox and make the method internal for your assembly. The other way is to use reflection and call the method. You can even create an extension method that will be available for all FrameworkElements. To make it even more extreme you can use expression trees to cache the method call and optimize the reflection. Here is the code:

internal static class FrameworkElementExtensions
{
    private static readonly Action<FrameworkElement, object> AddLogicalChildMethod = CreateAddLogicalChildMethod();
 
    private static Action<FrameworkElement, object> CreateAddLogicalChildMethod()
    {
        ParameterExpression instance = Expression.Parameter( typeof ( FrameworkElement ), "element" );
        ParameterExpression parameter = Expression.Parameter( typeof ( object ), "child" );
 
        MethodInfo methodInfo = typeof ( FrameworkElement ).GetMethod(
            "AddLogicalChild", BindingFlags.NonPublic | BindingFlags.Instance );
        MethodCallExpression method = Expression.Call( instance, methodInfo, parameter );
 
        Expression<Action<FrameworkElement, object>> lambda =
            Expression.Lambda<Action<FrameworkElement, object>>( method, instance, parameter );
 
        return lambda.Compile();
    }
 
    internal static void AddLogicalChild( this FrameworkElement element, object child )
    {
        AddLogicalChildMethod( element, child );
    }
}

You can find a sample solution here. Go play with it.

That its all for now folks. Next time I will show you how to create a generic adorner that can be used to decorate elements multiple times at different positions.