Tag Archives: WPF

XAML guidelines: interviews of WPF masters

Getting back to work this morning, I opened my Google Reader to have a look at the RSS feeds I’m reading.

I found a nice video on Channel9: “XAML Guidelines, Part 2”. The first episode, where Jaime Rodriguez interviews 3 people from Identity Mines is also available on Channel9 (unfortunately, the sound is rather poor on this episode…).

This time, Jaime meets up with Unni Ravindranathan from the Expression Blend team. During the shot, they open the Blend source code project inside Blend (sounds nice isn’t it :p). Unni explains the structure of the project, their conventions, how resources are used, etc.

I think Blend is an application we can learn a lot from. If you’re also interested to understand what architecture Blend uses, you can check out this post from Paul Stovell.

Here are some notes I took while watching the video:

  • Blend is shipped with 2 themes: Expression Light & Expression Dark
  • Blend resources are stored in (only !) 3 resources dictionaries
  • Resources are categorized into Colors, Brushes and Styles
  • Blend defines a set of margins and thicknesses that are used in the entire application to ensure a consistency across the different layouts
  • By convention, Name and Key properties are always defined first in the XAML
  • Properties might be spitted over several lines, if this is the case; properties are grouped together by types (style, size, appearance…)
  • Blend 3 will add extensibility and improve XAML code generation:
      – Name will always be the first property
      – Better control over how the XAML is formatted
  • Name everything versus name nothing? Blend names almost everything, it helps UI automation
  • Static resources versus dynamic resources? No big performance impact, Blend mostly uses dynamic resources
  • When design time doesn’t work fine in Blend
      – An exception can occur when Blend is creating the control because the running process is Blend itself and not the application we are creating
      – Add tests to check if code is running in design mode (you can use System.ComponentModel.DesignerProperties.GetIsInDesignMode(DependencyObject) method)
      – Debug Blend process by attaching an instance of Visual Studio to Blend
  • Blend is a big application:
      – 300 000 lines of XAML
      – 500 000 lines of C#

If you want more information about fixing error that we can have in Blend (while the application works properly at run time), you can check out this post of Jaime.

How to attach commands to any UIElement ?

In this blog, I already wrote 2 posts about attached properties. The more I play with this new WPF concept, the more I like it. Today at work, I found one new nice use of attached properties, and because it is this time reusable, I decided to share my experience here.

If you’re familiar with WPF, then you’re probably familiar with Commands. Commands are a new concept in WPF, here is the introduction from MSDN documentation:

Commanding is an input mechanism in Windows Presentation Foundation (WPF) which provides input handling at a more semantic level than device input. Examples of commands are the Copy, Cut, and Paste operations found on many applications.

Commands help you to decouple your UI from its execution logic and also simplify the process of enabling and disabling controls regarding the state of the command. If you want more details about Commands, you can check out this nice post from Marlon Grech.

You can attach a command to a Button using its Command property (you might also use CommandParameter and CommandTarget properties in some cases). To be more precise, elements that support Command must implement the ICommandSource interface:

public interface ICommandSource
{
ICommand Command { get; }
object CommandParameter { get; }
IInputElement CommandTarget { get; }
}

If you open Reflector and lookup for this interface, you’ll discover that 3 controls implement this interface:

  • MenuItem
  • ButtonBase
  • Hyperlink

In the project I’m working on at work, I had to find out a way to surpass 2 limitations:

  • Defining commands on other controls than MenuItem, ButtonBase and Hyperlink
  • Defining commands that could be triggered on other event than MouseLeftButtonUp

As you can imagine, I found a way to do that using… attached properties ! Basically I defined an attached property that I called MouseDoubleClickCommandProperty. This command enables you to attach a ICommand to ANY UIElement that will be triggered when the control is double clicked.

The MouseDoubleClickCommandProperty register a PropertyChangedCallback so that when the target changes, I can register on the UIElement.MouseDownEvent event. By looking the ClickCount property of the MouseButtonEventArgs parameter, I can check the MouseDownEvent comes from a DoubleClick event, and then trigger the associated command.

A nice example of this concept can be found in a TreeView. Imagine you want to start an action when a particular node in your TreeView is double clicked. The basic way to do that is to register the MouseDoubleClick event on the control. The new way to do the same thing is to use the MouseDoubleClickCommandProperty attached propery. Here is an example that shows how to do that in a hierarchical data template:


    
        
        
    

As you can see, by using the MouseDoubleClickCommand attached property is becomes possible to attach the command to a StackPanel ! Moreoever, because we might need to pass parameter to the ICommand, I also defined another attached properties that can hold any parameter you want, this is the MouseEventParameterProperty.

Similarly, we can imagine to trigger Commands when a RightClick occurs (we would just have to define a new attached property to do so).

I did a sample application that demonstrates the concept of this article. Because I didn’t have too much time, I used a ListBox instead of a TreeView. but the concepts are equivalent. Please feel free to comment 🙂