Yet another blog about WPF, Surface, SL, MVVM, NUI....

2011

2010

2009

2008

Tag - tips

Entries feed - Comments feed

 

[UPDATED] How to call the method from the base of the base of the current class ? (base.base.MyMethod)

11 May 2011

Today I encountered a tricky need in some custom control. It was inheriting from the TabControl but I didn’t want all its feature. Especially I didn’t want it to update the SelectedContent dependency property because it was keeping a strong reference to a ViewModel and keeping it away from the garbage collector.

Continue reading...

2 comments 2 trackbacks one attachment

 

What ? Dynamic resources creates Memory leaks in WPF 3.5 (SP1) ???

27 March 2011

Everyone is told to not use DynamicResource during its childhood in WPF-(wonder)land. They are simply evil and they kill the app performance. Sometimes, we fall in the dark side of the force and use them effectively to be sure that the application will follow the trend and suits itself well. This is not as bad as it seems and it is in fact sometimes necessary and wanted.

 But today, while I was trying to improve the performance and the memory usage of a WPF application I work on, I discovered that they were also creating memory leaks! I felt betrayed. I was using them and they put a knife in my back while I trusted them to be useful. 


In this post we will see how it can happens, and how to solve this (little) issue.

Continue reading...

no comment one trackback

 

VS Tip : how to locate the active document in the solution explorer using a shortcut

4 November 2010

When you have multiple projects in your solution, you often want to locate the active document in the solution explorer. There is a great option in Visual Studio which can do it for you all the time : “View.TrackActivityInSolutionExplorer”.

 

But if you do not want (as me) to turn it on all the time, there is no specific option or shortcut. So I have created a little macro which make my life easier. It simply turn on then off the option resulting by centering the active document in the solution explorer.

 

Here is the macro ( I put the Alt-T shorcut on it) :

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Public Module Utilities
Public Sub TrackProjectItem()
DTE.ExecuteCommand("View.TrackActivityInSolutionExplorer")
DTE.ExecuteCommand("View.TrackActivityInSolutionExplorer")
End Sub
End Module


Shout it kick it on DotNetKicks.com



no comment no trackback

 

How to create an hand writing to text control (ink recognizer)

25 October 2010

When building a (multi)touch application you may need one nice feature : translate hand-written text to real words. This open a whole new world full of possibilities like starting some actions when keywords are recognized or simply allow the users to write some text for later use. 

In this post we'll see all the step to create an hand writing to text control and how to tune it.

Continue reading...

one comment no trackback

 

How to create your own control library (how-to + tips)

3 October 2010

Reusability and factorizing are maybe the most commons things you want and use when you are developing applications. In WPF it often means creating controls library (i don’t mean UserControl) that will be easy to use in multiple applications.


In this post we'll see all the step to create a control library useable in differents projects.

The example to illustrate the theory will be to create an headered control.

 

PS: note that it already exists in the framework under the nice name of GroupBox.

Creating a control library

Foundation of the project

The first step is to use the VS2010 Wizard named "WPF Custom control library" to create the library which will contain the controls. We will name it, by excess of modesty : “AmazingsWPFControls” !

 

As you can see, VS has created some files and directory for us :

project tree

 

 

Let’s take them one by one ! The “Themes\generic.xaml” file is where the WPF engine, when it loads your control, looks for it’s theme aka. a style setting a template. Here is its content :

<Style TargetType="{x:Type local:CustomControl1}">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type local:CustomControl1}">
                <Border Background="{TemplateBinding Background}"
 BorderBrush="{TemplateBinding BorderBrush}"
                        BorderThickness="{TemplateBinding BorderThickness}">
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

 

The “AssemblyInfo.cs” file which contains a specific attribute :" ThemeInfo”. It tells the framework where to look for the theme files. Usually it is used like this :

[assembly: ThemeInfo(
ResourceDictionaryLocation.None, 


    //where theme specific resource dictionaries are located
//(used if a resource is not found in the page,
// or application resource dictionaries)
ResourceDictionaryLocation.SourceAssembly 


    //where the generic resource dictionary is located
//(used if a resource is not found in the page,
// app, or any theme specific resource dictionaries)
)]

 

The “CustomControl1.cs” which is an empty custom control the wizard created for you(how kind of him). Its content is interesting because it show you that you have to override the MetaData of the newly created control to force the WPF engine using the style defined in the generic.xaml file.

public class CustomControl1 : Control
{
static CustomControl1()
{
DefaultStyleKeyProperty.OverrideMetadata(typeof(CustomControl1),
new FrameworkPropertyMetadata(typeof(CustomControl1)));
}
}

 

 

Each time you want to add a new custom control to the library, you will have to reproduce each of these steps. Of course, the wizard to add a new Custom Control can do it for you but its always a good thing to know how it works. In our case we’ve to rename CustomControl1 to HeaderedControl.

 

Here we are with the foundation of the library. Now we are going to add a template and behaviors to the control.

 

Choose the more appropriated base class

By default the wizard make the control a inherit from the Control class but there are differents options that you may consider for base class :

  • Control : This is a base class which lets you the most freedom but the most to do !
  • ContentControl : This is a good choice if the control will be used to represent a single piece of content.
  • HeaderedContentControl : This is a good choice to represent a single element with an header.
  • ItemsControl: This is a good choice if the control will be used to represent a list of items.

 

 

In our case the best choice should be to inherit from HeaderedContentControl  but we will prefer the ContentControl for demonstration purpose. Note that it meets the specifications: we will represent a single element with an header.

 

Adding a Template and some behaviors to the control

Setting the template of the control

Unlike UserControl there is no code-behind and you set the template of the control by creating a style in the generic.xaml file. This also means that it’s not possible to access the elements via their names because the control and its representation are linked together only at runtime. But don’t worry, you can still access the differents parts following the steps described in this post.

 

 

One of the best practice is to name the revelants parts of your control prefixed with “PART”. By revelants parts, I mean the elements which together build the behavior of your control : for example the track of the slider control is named “PART_Track”. This best practice make your control re-templatable by designer which will know that the controls prefixed by “PART_” are mandatory in the new template they are building. Finally, the parts are declared in the control class via an attribute “TemplatePart” defining the name and the aimed type of control. So in our example, we’ll add a part named “PART_Header which will be the header :

 

/// <summary>
/// A control displaying an header at the top of its content.
/// </summary>    
[TemplatePart(Name = "PART_Header", Type = typeof(Border))]
public class HeaderedControl : Control
{
  // ...
}

 

Adding a content to the control

To add and display a content two things are needed : a property containing the content and a place in the template to display it. The content can be of any type of your choice and is usually placed in the Content property for ContentControl and the Items property for ItemsControl. This is the default behavior but you can override it and tell which property is the content by using the ContentPropertyAttribute on the control’s class :

[ContentPropertyAttribute("Content")]
public class HeaderedControl : ContentControl { // ... }

 

Then, in the template, you define where the content is displayed using a ContentPresenter that you can place where you wants depending of the need. We also use a TemplateBinding to bind the content of the class to the ContentPresenter. In our case we add the content under the header :

<Style TargetType="{x:Type local:HeaderedControl}">
   <Setter Property="Template">
       <Setter.Value>
           <ControlTemplate TargetType="{x:Type local:HeaderedControl}">
               <DockPanel>
                   <Border x:Name="PART_Header" DockPanel.Dock="Top" Background="{TemplateBinding Background}"
                           BorderBrush="{TemplateBinding BorderBrush}"
                           BorderThickness="{TemplateBinding BorderThickness}" />
                   <ContentPresenter Content="{TemplateBinding Content}" />
               </DockPanel>
           </ControlTemplate>
       </Setter.Value>
   </Setter>
</Style>

 

 

Adding a bindable property to the control

Adding a property to your control is quite useful if you want to permit some customization of its behavior. This is something very common that you use often without noticing it : every attribute you set in the XAML is simply a property of the controls you use.

 

In our case there is a lot which are already here because of our inheritance of FrameworkElement. But let’s said that we want to add another one all we have to do is do declare a new dependency property and its accessor as in the code behind. In our case we add two property : the header (of type Object) and the position of the header in the control. So we have this class :

public class HeaderedControl : ContentControl
{
  static HeaderedControl()
  {
      DefaultStyleKeyProperty.OverrideMetadata(typeof(HeaderedControl),
          new FrameworkPropertyMetadata(typeof(HeaderedControl)));
  }
 
  #region Header
 
  /// <summary>
  /// Header Dependency Property
  /// </summary>
  public static readonly DependencyProperty HeaderProperty =
      DependencyProperty.Register("Header", typeof(object), typeof(HeaderedControl),
          new FrameworkPropertyMetadata((object)null));
 
  /// <summary>
  /// Gets or sets the Header property. This dependency property 
  /// indicates the header to display.
  /// </summary>
  public object Header
  {
      get { return (object)GetValue(HeaderProperty); }
      set { SetValue(HeaderProperty, value); }
  }
 
  #endregion
 
  #region HeaderPosition
 
  /// <summary>
  /// HeaderPosition Dependency Property
  /// </summary>
  public static readonly DependencyProperty HeaderPositionProperty =
      DependencyProperty.Register("HeaderPosition", typeof(HeaderPosition), typeof(HeaderedControl),
          new FrameworkPropertyMetadata(HeaderPosition.Top));
 
  /// <summary>
  /// Gets or sets the HeaderPosition property. This dependency property 
  /// indicates ....
  /// </summary>
  public HeaderPosition HeaderPosition
  {
      get { return (HeaderPosition)GetValue(HeaderPositionProperty); }
      set { SetValue(HeaderPositionProperty, value); }
  }
 
  #endregion
 
 
  /// <summary>
  /// Defines where to place the header
  /// </summary>
  public enum HeaderPosition : int
  {
      /// <summary>
      /// The header is positioned on the left.
      /// </summary>
      Left = 0,
 
      /// <summary>
      /// The header is positioned at the top.
      /// </summary>
      Top = 1,
 
      /// <summary>
      ///  The header is positioned on the right.
      /// </summary>
      Right = 2,
 
      /// <summary>
      ///  The header is positioned at the bottom.
      /// </summary>
      Bottom = 3,
 
  }
}
 

Now let’s use these properties in the template to show and place the header at the right position. We will add another content presenter to display the header and we’ll use a converter to convert the header position into the correct DockPanel.Dock value (only the revelant XAML is showed) :

<ControlTemplate TargetType="{x:Type local:HeaderedControl}">
  <Border Background="{TemplateBinding Background}" 
          BorderBrush="{TemplateBinding BorderBrush}"
          BorderThickness="{TemplateBinding BorderThickness}">
      <DockPanel>
          <Border x:Name="PART_Header" 
              DockPanel.Dock="{Binding PositionOfTheHeader,
              RelativeSource={RelativeSource Mode=TemplatedParent},
              Converter={conv:HeaderPositionToDockPositionConverter}}">
              <ContentPresenter Content="{TemplateBinding Header}" />
          </Border>
          <ContentPresenter Content="{TemplateBinding Content}" />
      </DockPanel>
  </Border>
</ControlTemplate>
Adding a custom command to the control

Adding a command to our control is not as straightforward as I thought before to try Smile but here is the guideline is used to make it work fine :

  1. Create the RoutedCommand of your choice in the control class,
  2. Create a private method which will be called when the command is executed,
  3. Register a Class Command binding of this command in the static constructor of the control (you can think of it as a static command binding which will be called each time the command is executed),
  4. In the handler of the class command binding gets the sender of the command, cast it to your class and call the private method you created just before.

 

In our case there no really need of a command but lets say that we will add a command which sets the position of the header property to the “Top” value we will results with this code (against only the revelant part):

static HeaderedControl()
{
DefaultStyleKeyProperty.OverrideMetadata(typeof(HeaderedControl),
   new FrameworkPropertyMetadata(typeof(HeaderedControl)));
 
//Instanciate the command
MoveHeaderToTopCommand = new RoutedUICommand("MoveHeaderToTop",
   "MoveHeaderToTop", typeof(HeaderedControl));
 
//Create the command binding
CommandBinding moveHeaderToTopCommandBinding =
   new CommandBinding(MoveHeaderToTopCommand, 
                  MoveHeaderToTopCommand_Executed,
                  MoveHeaderToTopCommand_CanExecute);
 
CommandManager.
   RegisterClassCommandBinding(typeof(HeaderedControl), 
                     moveHeaderToTopCommandBinding);
}
 
 
static void MoveHeaderToTopCommand_Executed(
        object sender, ExecutedRoutedEventArgs e)
{
    HeaderedControl headeredControl = 
                 sender as HeaderedControl;
    if (headeredControl != null)
       headeredControl.moveHeaderToTop();
}
 
static void MoveHeaderToTopCommand_CanExecute(object sender, 
       CanExecuteRoutedEventArgs e)
{
e.CanExecute = true;
}
 
private void moveHeaderToTop()
{
this.PositionOfTheHeader = HeaderPosition.Top;
}
 

The command is then useable as any other WPF command in your application and you can even use parameters if needed.

 

Adding a Routed event to the control

Adding an event can be useful to notify the others part of your application that an action occurred in the control or to deliver informations.

 

To add an event here are the guideline :

  1. (optionnal) Creates the events args inherithing from RoutedEventArgs that you will use
  2. Declare the event handler of the event,
  3. Declare the RoutedEvent with the name of your choice,
  4. Creates the accesor for a simplier use,
  5. (optionnal) creates a raiseYourEvent method to raise the event easily.

 

 

Now lets assume we wants to raise an event when the header is clicked. For this we’ll subscribe to the Header “MouseDown” event in the OnApplyTemplate() method and raise a newly created event in its handler :

public override void OnApplyTemplate()
{
   base.OnApplyTemplate();
 
   PART_Header = this.GetTemplateChild("PART_Header") as Border;
   if (PART_Header == null)
       throw new ArgumentNullException(
           "Can't find PART_Header in the HeaderedControl template.");
   PART_Header.MouseDown += (a, b) => { RaiseHeaderClickedEvent(); };
}
 
 
/// <summary>
/// the event handler delegate
/// </summary>
public delegate void HeaderClickedEventHandler(object sender, 
    HeaderClickedEventArgs e);
 
/// <summary>
/// Create a custom routed event by first 
/// registering a RoutedEventID
/// This event uses the bubbling routing strategy
/// </summary>
public static readonly RoutedEvent HeaderClickedEvent = 
    EventManager.RegisterRoutedEvent(
   "HeaderClicked", RoutingStrategy.Bubble, 
   typeof(HeaderClickedEventHandler), typeof(HeaderedControl));
 
/// <summary>
/// Occurs when the header is clicked.
/// </summary>
public event RoutedEventHandler HeaderClicked
{
   add { AddHandler(HeaderClickedEvent, value); }
   remove { RemoveHandler(HeaderClickedEvent, value); }
}
 
/// <summary>
/// Raises the header clicked event.
/// </summary>
void RaiseHeaderClickedEvent()
{
   HeaderClickedEventArgs newEventArgs = 
    new HeaderClickedEventArgs(
            HeaderedControl.HeaderClickedEvent);
   RaiseEvent(newEventArgs);
}
 
/// <summary>
/// The header has been clicked event args
/// </summary>
public class HeaderClickedEventArgs : RoutedEventArgs
{
   /// <summary>
   /// Initializes a new instance of the
   /// <see cref="HeaderClickedEventArgs"/> class.
   /// </summary>
   /// <param name="routedEvent">The routed event.</param>
   public HeaderClickedEventArgs(RoutedEvent routedEvent) 
     : base(routedEvent) { }
}

 

 

 

Ease the use of your library by declaring an URL as an XML namespace

 

What is it ? Simply that when you will use the controls in another page you will not declare the XML namespace via an assembly name but via an URL easy to remember. Example : 

<Window x:Class="AmazingWPFControls.Showcase.MainWindow"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
 xmlns:controls="http://blog.lexique-du-net.com/wpf/AmazingsWPFControls"
/>


Why to do it ?

So now all you have to do is to create a bright new control Smile

Interesting links



Shout it kick it on DotNetKicks.com

no comment 2 trackbacks

 

How to create an animated expander

21 September 2010

The expander control can be used in a lot of situations but the one proposed by default is quite "rigid".

In this post we will discover how to animate it quite simply just via XAML !

The WPF engine lets us redefine the template of the controls and we'll just do that.

The goal aimed

What we aim is to get the same functionnality as the original expander.
This is not as simple as we tought and I've seen a lot of expander loosing some of their behaviors when they became "animated" : original value of IsExpanded ignored, ExpandDirection ignored, etc...

Getting the necessary files

The files needed are :

  1. the original control template of the Expander
  2. the expander's button style which are linked to it


To get them, I used Expression Blend folowing the MSDN steps on this page : http://msdn.microsoft.com/en-us/library/cc294908.aspx

Especially for you, they are also linked to the post :) !. Here is the expander original template : 

<ControlTemplate TargetType="{x:Type Expander}">
  <Border SnapsToDevicePixels="true" 
      Background="{TemplateBinding Background}" 
      BorderBrush="{TemplateBinding BorderBrush}" 
      BorderThickness="{TemplateBinding BorderThickness}" 
      CornerRadius="3">
    <DockPanel>
      <ToggleButton FocusVisualStyle="{StaticResource ExpanderHeaderFocusVisual}" 
              Margin="1" 
              MinHeight="0" 
              MinWidth="0" 
              x:Name="HeaderSite" 
              Style="{StaticResource ExpanderDownHeaderStyle}" />
      <ContentPresenter Focusable="false" 
                Visibility="Collapsed" 
                HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" 
                Margin="{TemplateBinding Padding}" 
                x:Name="ExpandSite"   />
    </DockPanel>
  </Border>
  <ControlTemplate.Triggers>
    <Trigger Property="IsExpanded" Value="true">
      <Setter Property="Visibility" TargetName="ExpandSite" Value="Visible"/>
    </Trigger>
    <Trigger Property="ExpandDirection" Value="Right">
      <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Right"/>
      <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Left"/>
      <Setter Property="Style" TargetName="HeaderSite" 
                     Value="{StaticResource ExpanderRightHeaderStyle}"/>
    </Trigger>
    <Trigger Property="ExpandDirection" Value="Up">
      <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Top"/>
      <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Bottom"/>
      <Setter Property="Style" TargetName="HeaderSite" 
                    Value="{StaticResource ExpanderUpHeaderStyle}"/>
    </Trigger>
    <Trigger Property="ExpandDirection" Value="Left">
      <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Left"/>
      <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Right"/>
      <Setter Property="Style" TargetName="HeaderSite" 
                    Value="{StaticResource ExpanderLeftHeaderStyle}"/>
    </Trigger>
    <Trigger Property="IsEnabled" Value="false">
      <Setter Property="Foreground" 
               Value="{DynamicResource {x:Static SystemColors.GrayTextBrushKey}}"/>
    </Trigger>
  </ControlTemplate.Triggers>
</ControlTemplate>



Add the new behavior to the expander

As you can see, the original template plays on the Visibility property to expand or collapse the "expandable" part.

We will change that and add a scaling transformation on the "expendable part" of the control that we'll animate at the right moment (when the IsExpanded property value change).
Also we'll not use simple DataTrigger but MultiTrigger because we have to starts differents animation depending of the Expand direction.

The result is a quite simple but lenghty XAML file (the AnimatedExpanderStyles is linked to the post) :

<Style x:Key="ourAnimatedExpanderStyle" TargetType="{x:Type Expander}">
<Setter Property="Foreground"
             Value="{DynamicResource {x:Static SystemColors.ControlTextBrushKey}}" />
<Setter Property="Background" Value="Transparent" />
<Setter Property="HorizontalContentAlignment" Value="Stretch" />
<Setter Property="VerticalContentAlignment" Value="Stretch" />
<Setter Property="BorderBrush" Value="Transparent" />
<Setter Property="BorderThickness" Value="1" />
<Setter Property="Template">
  <Setter.Value>
    <ControlTemplate TargetType="{x:Type Expander}">
 
      <ControlTemplate.Resources>
        <ResourceDictionary>
          <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary
     Source="/My.Assembly;component/AnimatedExpander/AnimatedExpanderStyles.xaml" />
        </ResourceDictionary.MergedDictionaries>
          <Storyboard x:Key="scaleYUp">
            <DoubleAnimation From="0" To="1" Duration="0:0:0.25" 
Storyboard.TargetName="ExpandSite"
Storyboard.TargetProperty="(FrameworkElement.LayoutTransform).(ScaleTransform.ScaleY)" />
          </Storyboard>
          <Storyboard x:Key="scaleYDown">
            <DoubleAnimation Fr  om="1" To="0" Duration="0:0:0.25" 
Storyboard.TargetName="ExpandSite"
Storyboard.TargetProperty="(FrameworkElement.LayoutTransform).(ScaleTransform.ScaleY)" />
          </Storyboard>
          <Storyboard x:Key="scaleXUp">
            <DoubleAnimation From="0" To="1" Duration="0:0:0.25"
Storyboard.TargetName="ExpandSite"
Storyboard.TargetProperty="(FrameworkElement.LayoutTransform).(ScaleTransform.ScaleX)" />
          </Storyboard>
          <Storyboard x:Key="scaleXDown">
            <DoubleAnimation From="1" To="0" Duration="0:0:0.25"  
Storyboard.TargetName="ExpandSite"
Storyboard.TargetProperty="(FrameworkElement.LayoutTransform).(ScaleTransform.ScaleX)" />
          </Storyboard>
        </ResourceDictionary>
      </ControlTemplate.Resources>
 
      <Border BorderBrush="{TemplateBinding BorderBrush}"
          BorderThickness="{TemplateBinding BorderThickness}"
          Background="{TemplateBinding Background}" CornerRadius="3"
                SnapsToDevicePixels="true">
        <DockPanel>
          <ToggleButton
              IsChecked="{Binding Path=IsExpanded, Mode=TwoWay, 
                                    RelativeSource={RelativeSource TemplatedParent}}"
              Margin="1" MinHeight="0" MinWidth="0" x:Name="HeaderSite"
              Style="{StaticResource ExpanderDownHeaderStyle}">
            <ContentPresenter Content="{TemplateBinding Header}"
                ContentTemplate="{TemplateBinding HeaderTemplate}"
                ContentTemplateSelector="{TemplateBinding HeaderTemplateSelector}" Margin="1"
                Focusable="false" />
          </ToggleButton>
 
          <ContentPresenter x:Name="ExpandSite"
              HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
              VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
              Margin="{TemplateBinding Padding}" Focusable="false">
            <ContentPresenter.LayoutTransform>
              <ScaleTransform x:Name="scaleTransform" ScaleX="1" ScaleY="1" />
            </ContentPresenter.LayoutTransform>
          </ContentPresenter>
        </DockPanel>
      </Border>
      <ControlTemplate.Triggers>
        <MultiTrigger>
          <MultiTrigger.Conditions>
            <Condition Property="IsExpanded" Value="True" />
            <Condition Property="ExpandDirection" Value="Up" />
          </MultiTrigger.Conditions>
          <MultiTrigger.EnterActions>
            <BeginStoryboard Storyboard="{StaticResource scaleYUp}" />
          </MultiTrigger.EnterActions>
          <MultiTrigger.ExitActions>
            <BeginStoryboard Storyboard="{StaticResource scaleYDown}" />
          </MultiTrigger.ExitActions>
        </MultiTrigger>
 
        <MultiTrigger>
          <MultiTrigger.Conditions>
            <Condition Property="IsExpanded" Value="True" />
            <Condition Property="ExpandDirection" Value="Down" />
          </MultiTrigger.Conditions>
          <MultiTrigger.EnterActions>
            <BeginStoryboard Storyboard="{StaticResource scaleYUp}" />
          </MultiTrigger.EnterActions>
          <MultiTrigger.ExitActions>
            <BeginStoryboard Storyboard="{StaticResource scaleYDown}" />
          </MultiTrigger.ExitActions>
        </MultiTrigger>
 
        <MultiTrigger>
          <MultiTrigger.Conditions>
            <Condition Property="IsExpanded" Value="True" />
            <Condition Property="ExpandDirection" Value="Left" />
          </MultiTrigger.Conditions>
          <MultiTrigger.EnterActions>
            <BeginStoryboard Storyboard="{StaticResource scaleXUp}" />
          </MultiTrigger.EnterActions>
          <MultiTrigger.ExitActions>
            <BeginStoryboard Storyboard="{StaticResource scaleXDown}" />
          </MultiTrigger.ExitActions>
        </MultiTrigger>
        <MultiTrigger>
          <MultiTrigger.Conditions>
            <Condition Property="IsExpanded" Value="True" />
            <Condition Property="ExpandDirection" Value="Right" />
          </MultiTrigger.Conditions>
          <MultiTrigger.EnterActions>
            <BeginStoryboard Storyboard="{StaticResource scaleXUp}" />
          </MultiTrigger.EnterActions>
          <MultiTrigger.ExitActions>
            <BeginStoryboard Storyboard="{StaticResource scaleXDown}" />
          </MultiTrigger.ExitActions>
        </MultiTrigger>
 
        <Trigger Property="ExpandDirection" Value="Down">
          <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Bottom" />
          <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Top" />
 
        </Trigger>
        <Trigger Property="ExpandDirection" Value="Up">
          <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Top" />
          <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Bottom" />
          <Setter Property="Style" TargetName="HeaderSite"
              Value="{DynamicResource ExpanderUpHeaderStyle}" />
 
        </Trigger>
        <Trigger Property="ExpandDirection" Value="Right">
          <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Right" />
          <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Left" />
          <Setter Property="Style" TargetName="HeaderSite"
              Value="{DynamicResource ExpanderRightHeaderStyle}" />
 
        </Trigger>
 
        <Trigger Property="ExpandDirection" Value="Left">
          <Setter Property="DockPanel.Dock" TargetName="ExpandSite" Value="Left" />
          <Setter Property="DockPanel.Dock" TargetName="HeaderSite" Value="Right" />
          <Setter Property="Style" TargetName="HeaderSite"
              Value="{DynamicResource ExpanderLeftHeaderStyle}" />
        </Trigger>
 
      </ControlTemplate.Triggers>
    </ControlTemplate>
  </Setter.Value>
</Setter>
</Style>

Conclusion

To use this Expander we have to use this little snippet :

<Expander Header="Our text" ExpandDirection="Up" 
               Style="{StaticResource ourAnimatedExpanderStyle}"    >
    <!--- content here ! --->
</Expander>



Everythings seems to works fine and all the behaviors of the original expander are still here !

Shout it kick it on DotNetKicks.com




2 comments 2 trackbacks 2 attachments

 

Execute a command on a specified control when clicking on a button

16 June 2010

Today another example of the powerful ramora pattern : execute a RoutedCommand on an Control when you click on a button outside of the aimed control scope.

When is it useful ? : for example when you use the infragistics grid (xamdatagrid) and you want to execute the command which remove the selected row from a button outside of the grid. You then have to exectue the DeleteSelectedDataRecords command on the grid from a button which is outside of the scope of the grid ... then this behavior is useful !

Our implementation will also show how we can apply the "Weak Events pattern" with the dependency property trick (attached property / ramora pattern).

And of course this example can be adapted to subscribe on any event you wants and not only the click of a button.

The behavior itself

Our behavior will listen to the click button, and the handling of the click event will execute the routed command on the target element.

public class ExecuteCommandOnControl : DependencyObject
{
  #region Command
 
  /// <summary>
  /// Command Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty RoutedCommandProperty =
    DependencyProperty.RegisterAttached("RoutedCommand", typeof(RoutedCommand)
	     , typeof(ExecuteCommandOnControl));
 
  /// <summary>
  /// Gets the Command property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static RoutedCommand GetRoutedCommand(DependencyObject d)
  {
    return (RoutedCommand)d.GetValue(RoutedCommandProperty);
  }
 
  /// <summary>
  /// Sets the Command property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetRoutedCommand(DependencyObject d, RoutedCommand value)
  {
    d.SetValue(RoutedCommandProperty, value);
  }
 
  #endregion
 
  #region IInputElement
  /// <summary>
  /// IInputElement Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty TargetProperty =
    DependencyProperty.RegisterAttached("Target", typeof(IInputElement), 
	   typeof(ExecuteCommandOnControl),
      new FrameworkPropertyMetadata(null,
        new PropertyChangedCallback(OnTargetChanged)));
 
  /// <summary>
  /// Gets the IInputElement property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static IInputElement GetTarget(DependencyObject d)
  {
    return (IInputElement)d.GetValue(TargetProperty);
  }
 
  /// <summary>
  /// Sets the IInputElement property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetTarget(DependencyObject d, IInputElement value)
  {
    d.SetValue(TargetProperty, value);
  }
 
  /// <summary>
  /// Handles changes to the IInputElement property.
  /// </summary>
  private static void OnTargetChanged(DependencyObject d, 
     DependencyPropertyChangedEventArgs e)
  {
    Button button = d as Button;
 
    if (button != null)
    {
      ButtonClickEventManager.AddListener(button, _customEventListener);
 
    } else
    {
      throw 
	  new ArgumentException("This behavior can only be installed on non-null Button !");
    }
  }
 
  #endregion
 
  private static CustomEventListener _customEventListener = new CustomEventListener();
 
}



WeakEvents

So what is the class CustomEventListener ? This is the object which will handle the click on the button. This class implements the interface IWeakEventListener which is a necessary things to use the Weak event pattern.

We will then not subscribe the click event with the usual way ( using the operator +=) but by calling a WeakEventManager of our own : ButtonClickEventManager.

This manager will then keep a weak reference of our listener and the button on which we operate will then be free to be garbage collected. Otherwise, every button on which we subscribe would be keeped in the memory because each one would be connected to our behavior...

Here is the CustomEventListener class :

public class CustomEventListener : IWeakEventListener
{
  #region IWeakEventListener Members
  public bool ReceiveWeakEvent(Type managerType, object sender, EventArgs e)
  {
    if (managerType == typeof(ButtonClickEventManager))
    {
      var target = 
	  ExecuteCommandOnControl.GetTarget(sender as DependencyObject);
      var command = 
	  ExecuteCommandOnControl.GetRoutedCommand(sender as DependencyObject);
 
      if (target == null || command == null) return true;
 
      command.Execute(null, target);
      return true;
    } else
    {
      return false;
    }
  }
  #endregion
}

And here is our WeakEventMAnager :

public class ButtonClickEventManager : WeakEventManager
{
 
  public static void AddListener(Button source, 
       IWeakEventListener listener)
  {
    ButtonClickEventManager.
	   CurrentManager.ProtectedAddListener(source, listener);
  }
 
  public static void RemoveListener(Button source, 
       IWeakEventListener listener)
  {
    ButtonClickEventManager.
	   CurrentManager.ProtectedRemoveListener(source, listener);
  }
 
  protected override void StartListening(object source)
  {
    Button button = (Button)source;
    button.Click += this.OnButtonClick;
  }
 
  protected override void StopListening(object source)
  {
    Button button = (Button)source;
    button.Click -= this.OnButtonClick;
  }
 
  private void OnButtonClick(Object sender, RoutedEventArgs args)
  {
    base.DeliverEvent(sender, args);
  }
 
  private static ButtonClickEventManager CurrentManager
  {
    get
    {
      Type managerType = typeof(ButtonClickEventManager);
      ButtonClickEventManager manager = 
	  (ButtonClickEventManager)WeakEventManager.GetCurrentManager(managerType);
      if (manager == null)
      {
        manager = new ButtonClickEventManager();
        WeakEventManager.SetCurrentManager(managerType, manager);
      }
      return manager;
    }
  }
}



Example of use

Here a little example of how you can use it to launch the deleteSelected command of the infragistics datagrid from a button outside of the grid :

<Button Content="Delete selected"
  tools:ExecuteCommandOnControl.RoutedCommand="{x:Static igDP:DataPresenterCommands.DeleteSelectedDataRecords}"
  tools:ExecuteCommandOnControl.Target="{Binding ElementName=dataGrid}" />
<igDP:XamDataGrid Name="dataGrid" DataSource="{Binding Data}" />



Interesting readings



Shout it kick it on DotNetKicks.com Awaaz Up


2 comments 3 trackbacks

 

Binding to the selected items of a ListBox (or an another items controls)

13 June 2010

A problem you often meet when using MVVM is to get the selected items of an items control, especially Listbox.

You can easily bind the selected item or the current items but when multi selection comes in the way, it becomes harder because the SelectedItems (with an 's' property is not available to binding).

In this article we will discover an easy way to bind yourself with an attached property to the SelectedItems property of the ListBox control.



We will use the Ramora pattern discussed before to bind ourself to the ListBox's selectionChanged events and then update the target list when the selection change.

If the target list implements INotifyCollectionChanged we will update the listbox selection when this event is raised.

Here is the resulting code :

public class ListBoxSelectedItemsSyncher : DependencyObject
{
  private static List<Syncher> _synchers = new List<Syncher>();
 
  #region ListToSync
 
  /// <summary>
  /// ListToSync Attached Dependency Property
  /// </summary>
  public static readonly DependencyProperty ListToSyncProperty =
    DependencyProperty.RegisterAttached("ListToSync", 
	             typeof(IList), typeof(ListBoxSelectedItemsSyncher),
      new FrameworkPropertyMetadata((IList)new List<Object>(),
        FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, 
		       new PropertyChangedCallback(OnListToSyncChanged)));
 
 
  private static void OnListToSyncChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
  {
    ListBox listBox = d as ListBox;
 
    if(!(d is ListBox)
     throw new ArgumentException("ListBoxSelectedItemsSyncher is only applyable to Listbox");
 
    Syncher synch = (from Syncher syncher 
	              in _synchers where syncher.ListBox == listBox select syncher)
                             .FirstOrDefault();
    if (synch != null)
    {
      synch.ListToSync = e.NewValue as IList;
    } else
    {
      synch = new Syncher(listBox, e.NewValue as IList);
      _synchers.Add(synch);
      listBox.Unloaded += new RoutedEventHandler(listBox_Unloaded);
    }
  }
 
  static void listBox_Unloaded(object sender, RoutedEventArgs e)
  {
    ListBox listBox = sender as ListBox;
    Syncher synch = (from Syncher syncher 
	              in _synchers where syncher.ListBox == listBox select syncher)
                      .FirstOrDefault();
    if (synch != null)
    {
      _synchers.Remove(synch);
      synch.Dispose();
      synch = null;
    }
  }
 
  /// <summary>
  /// Gets the ListToSync property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static IList GetListToSync(DependencyObject d)
  {
    return (IList)d.GetValue(ListToSyncProperty);
  }
 
  /// <summary>
  /// Sets the ListToSync property.  This dependency property 
  /// indicates ....
  /// </summary>
  public static void SetListToSync(DependencyObject d, IList value)
  {
    d.SetValue(ListToSyncProperty, value);
  }
 
  #endregion
 
 
  internal class Syncher : IDisposable
  {
 
    private ListBox _listbox;
    public ListBox ListBox { get { return _listbox; } }
 
    private IList _listToSync;
    public IList ListToSync
    {
      get { return _listToSync; }
 
      set
      {
        detachTheListToSynch();
        _listToSync = value;
        attachTheListToSynch();
      }
    }
 
    public Syncher(ListBox listbox, IList listToSync)
    {
      _listbox = listbox;
      _listToSync = listToSync;
      attachTheListToSynch();
    }
 
    void collectionChangedList_CollectionChanged(object sender,
                        	NotifyCollectionChangedEventArgs e)
    {
      //Add new items   
      if (e.NewItems != null)
      {
        foreach (Object item in e.NewItems)
        {
          _listbox.SelectedItems.Add(item);
        }
      }
      if (e.OldItems != null)
      {
        foreach (Object item in e.OldItems)
        {
          _listbox.SelectedItems.Remove(item);
        }
      }
 
      if (e.Action == NotifyCollectionChangedAction.Reset)
        _listbox.SelectedItems.Clear();
 
      CommandManager.InvalidateRequerySuggested();
    }
 
    void _list_SelectionChanged(object sender, SelectionChangedEventArgs e)
    {
      if (_listToSync != null)
      {
        //Add new items                   
        foreach (Object item in e.AddedItems)
        {
          _listToSync.Add(item);
        }
        foreach (Object item in e.RemovedItems)
        {
          _listToSync.Remove(item);
        }
        CommandManager.InvalidateRequerySuggested();
      }
    }
 
    #region IDisposable Members
    public void Dispose()
    {
      if (_listbox == null) return;
      _listbox.SelectionChanged -= _list_SelectionChanged;
      detachTheListToSynch();
      _listbox = null;
    }
    #endregion
 
    #region private methods
    private void attachTheListToSynch()
    {
      _listbox.SelectionChanged -= _list_SelectionChanged;
      if (_listToSync == null) return;
 
      INotifyCollectionChanged collectionChangedList = null;
      if ((collectionChangedList = _listToSync as INotifyCollectionChanged) != null)
        collectionChangedList.CollectionChanged 
	  += new NotifyCollectionChangedEventHandler(collectionChangedList_CollectionChanged);
 
      //Update the selection with the new list
      _listbox.SelectedItems.Clear();
 
      foreach (var item in _listToSync)
        _listbox.SelectedItems.Add(item);
 
      _listbox.SelectionChanged 
	       += new SelectionChangedEventHandler(_list_SelectionChanged);
    }
 
    private void detachTheListToSynch()
    {
      INotifyCollectionChanged collectionChangedList = null;
      if ((collectionChangedList = _listToSync as INotifyCollectionChanged) != null)
        collectionChangedList.CollectionChanged -= collectionChangedList_CollectionChanged;
    }
    #endregion
 
  }
 }


Here we are.

Edit : I found out later an another version of the same feature made by Samuel Jack on his blog : http://blog.functionalfun.net/2009/02/how-to-databind-to-selecteditems.html !



Shout it kick it on DotNetKicks.com


no comment 3 trackbacks

 

[Performance tips] Use the system shadows instead of your own

27 April 2010

Today a fast and easy tip about shadows and performance.

In a project I have recently made, we've told the designer not to use BitmapEffects because they are performance killer. He so decided to create it's own shadows by duplicating each shape and make them looks like shadows(designer magic, voodoo things, etc...). I was then surprised to see that it kills performance too !


There is still the shaders effect which came with the 3.5 SP1 framework but they will be available only on vista or greater plateforms and their performance will depend of your graphic cards.

But we have an another ace in you deck : the system shadow which are quite fast even on software rendering!

Using it is quite easy :

  1. Add the PresentationFramework.Aero reference to your project,
  2. Add the following XML namespace : ”clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero”,
  3. Use the SystemDropShadowChrome element available with this namespace !



But there is a drawback : you can only produce squared shadows. But you can still play with the CornerRadius property to create simily round shadows.

Here is a little example of XAML code:

<UniformGrid
    xmlns:shadows="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero"
    Columns="2">
  <shadows:SystemDropShadowChrome Margin="25">
    <ListBox>
      <ListBoxItem Content="One item" />
      <ListBoxItem Content="Another item" />
      <ListBoxItem Content="Another third item" />
    </ListBox>
  </shadows:SystemDropShadowChrome >
 
  <shadows:SystemDropShadowChrome Margin="25" CornerRadius="800" Width="100" Height="100">
    <Ellipse Stroke="Black" Fill="White" />
  </shadows:SystemDropShadowChrome>
</UniformGrid>

Shadows screenshot

Shout it kick it on DotNetKicks.com




2 comments 3 trackbacks

 

Freeze brushes directly in the XAML to improve your application's performances

12 April 2010

When you read the MSDN guidelines to improve WPF's performances you can find that it's a good idea to freeze Freezable objects.

It's a quite easy thing to do via the code but it's quite harder to do it directly in the XAML. In this post we will see how to do so.

What are freezable objects

One upon a time, the MSDN said :

A Freezable is a special type of object that has two states: unfrozen and frozen. When unfrozen, a Freezable appears to behave like any other object. When frozen, a Freezable can no longer be modified.

A Freezable provides a Changed event to notify observers of any modifications to the object. Freezing a Freezable can improve its performance, because it no longer needs to spend resources on change notifications. A frozen Freezable can also be shared across threads, while an unfrozen Freezable cannot.



With this definition in mind, you surely had guess that it's a good thing to freeze them because and you surely want to do it... But how to do ?

Freeze freezable objects via the code

It's quite easy to do it in the code. The only thing do check is the property CanFreeze which tells you if you can or not freeze the Freezable object. You will then use this code : 

if (myBrush.CanFreeze)
{
    // Makes the brush unmodifiable.
    myBrush.Freeze();
}



Freeze them (with ice) in XAML

The tips is to know the good XML Namespace http://schemas.microsoft.com/winfx/2006/xaml/presentation/options.

The use in the XAML is then quite easy :

<LinearGradientBrush ice:Freeze="True" 
xmlns:ice="http://schemas.microsoft.com/winfx/2006/xaml/presentation/options" 
/>



Shout it kick it on DotNetKicks.com



no comment 2 trackbacks

 

Simple properties Mapper by reflection : stop copying manually each property of your objects !

8 April 2010

There is time when you have to copy each property of an object to one another. This is called mapping and it's very fastidious to do it by hand.

In this post we'll see how to create a method extension which do it for you in one line of code !

When can it be useful

Here is a non exhaustive list of usage you can find to this snippet:

  • You want to reload the previous state of an object without changing it's instance : just clone it as a snapshot and copy back the properties when you want,
  • You get's some Data Transfert Object coming from WCF/Web services and you want's to fill a specific object with this data,
  • etc ...



I surely know this is not the most efficient way to solve these problems, but this is fast to use/understand and easy to implements.

Let's jump to the code !

What's inside ? Quite a few things actually ! There is two object, the source in which we take the data and the target in which we fill in these datas.

I use reflection to obtain every property of the source and then I check on the target if a property exist with the same name. If yes I fill it with the value of the property in the source object.

I also added a filter which is a list of Property name which will be ignored by the "copy process".

With a little more time you can also add a dictionnary which may map a property name in the source to an another property name in the target if the name are note exactly the same... 

public static class PropetiesMapper{
	/// <summary>
    /// Copies all the properties of the "from" object to this object if they exists.
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    /// <param name="excludedProperties">Exclude these proeprties from the copy</param>
    public static void copyPropertiesFrom(this object to, object from, string[] excludedProperties)
    {
 
      Type targetType = to.GetType();
      Type sourceType = from.GetType();
 
      PropertyInfo[] sourceProps = sourceType.GetProperties();
      foreach (var propInfo in sourceProps)
      {
        //filter the properties
        if (excludedProperties != null
          && excludedProperties.Contains(propInfo.Name))
          continue;
 
        //Get the matching property from the target
        PropertyInfo toProp =
          (targetType == sourceType) ? propInfo : targetType.GetProperty(propInfo.Name);
 
        //If it exists and it's writeable
        if (toProp != null && toProp.CanWrite)
        {
          //Copty the value from the source to the target
          Object value = propInfo.GetValue(from, null);
          toProp.SetValue(to,value , null);
        }
      }
    }
 
    /// <summary>
    /// Copies all the properties of the "from" object to this object if they exists.
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    public static void copyPropertiesFrom(this object to, object from)
    {
      to.copyPropertiesFrom(from, null);
    }
 
    /// <summary>
    /// Copies all the properties of this object to the "to" object
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    public static void copyPropertiesTo(this object from, object to)
    {
      to.copyPropertiesFrom(from, null);
    }
 
    /// <summary>
    /// Copies all the properties of this object to the "to" object
    /// </summary>
    /// <param name="to">The object in which the properties are copied</param>
    /// <param name="from">The object which is used as a source</param>
    /// <param name="excludedProperties">Exclude these proeprties from the copy</param>
    public static void copyPropertiesTo(this object from, object to, string[] excludedProperties)
    {
      to.copyPropertiesFrom(from, excludedProperties);
    }
  }



So, do you still want to put an "Hand made" label on your object's mapping ? :-D

A more complex and complete tool

For those which wants something more powerful and complete : take a look at the automapper library on codeplex.

Shout it kick it on DotNetKicks.com



one comment 2 trackbacks

 

Binding on a Property which is not a DependencyProperty

5 April 2010

A lot of controls expose properties which are not DependencyProperties and then you can’t put a binding on it. On some other cases, you only have a getter as accessor and you can’t put a binding on it too…

This is for example the case for the ribbon’s group of the office ribbon or the converter’s parameter.

If you ever tried to do so, you surely had an exception throwned :

A 'Binding' cannot be set on the 'SetCEDEJDED' property of type 'Tralala'.
A 'Binding' can only be set on a DependencyProperty of a DependencyObject.


In this post we will discover a work-around…

The main idea is to use a kind of proxy/observer (a definition can be found in this post) which will reflect every change on the source object to the target object and vice versa.

Here are the main parts of the solution ..

Specification: the XAML code we'll use

Here is the code snippet which describe how we will use our proxy in the XAML. There will be no code-behind.

<Window x:Class="BindOnNonDependencyProperty.MainWindow" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:us="clr-namespace:BindOnNonDependencyProperty"
    Title="BindOnNonDependencyProperty" >
  <DockPanel >
    <TextBox x:Name="myTextBox" DockPanel.Dock="Top"  />
    <TextBox x:Name="monTextBlockCible"  DockPanel.Dock="Top"  />
    <us:ExtendedBinding Source="{Binding ElementName=myTextBox,Path=Text,Mode=TwoWay}"
              Target="{Binding ElementName=monTextBlockCible,Path=Text,Mode=TwoWay}"
              />
  </DockPanel>
</Window>



The correct base class for our proxy/observer

We will call it ExtendedBinding and it must be inherithing from DependencyObject at last to be abble to own DependencyProperty. But the only way to add a DependencyObject into our XAML is to add it into a resourceDictonary.

This is a drawnback because, by doing it, it will no more be into the control's tree and then it will be impossible to make a binding on one of it's property. Note that it's still possible to use it as a Target from another place in our XAML but you can't do a Binding on one of it's properties. This code will not work :

<Windows.Resources>
   <MyDependencyObject x:Key="myKey" MyProperty="{Binding Tralala, ElementName=myTarget}" />
</Windows.Resources>



Then to put it insode the control's tree, we only had to make it an UIElement will you say... No because in the actual version of the Framework you won't have inheritance of the DataContext and the use of the 'ElementName' binding will be prohibited. Hopefully, there is a solution, our proxy have to inherit from FrameworkElement and everything will work fine !

The DependencyProperties

We will add two dependencyProperties, one will be the target and the second will be the source.

These DP will be customize by using the FrameworkPropertyMetadata two enables these features :

  • Binding will be done using the TwoWay mode,
  • The UpdateSourceTrigger used will be the PropertyChanged event.


How it works

The core of our proxy is to override the DependencyObject's OnPropertyChanged method. Each change on the source or the target will update it's counterparty.

We have to take care not to fall into a loop : when we will update the target or the source we'll also raise a PropertyChanged event and we must ignore this one....


Final code

public class ExtendedBinding : FrameworkElement
  {
    #region Source DP
    //We don't know what will be the Source/target type so we keep 'object'.
    public static readonly DependencyProperty SourceProperty =
      DependencyProperty.Register("Source", typeof(object), typeof(ExtendedBinding),
      new FrameworkPropertyMetadata()
      {
        BindsTwoWayByDefault = true,
        DefaultUpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged,
      });
    public Object Source
    {
      get { return GetValue(ExtendedBinding.SourceProperty); }
      set { SetValue(ExtendedBinding.SourceProperty, value); }
    }
    #endregion
 
    #region Target DP
      //We don't know what will be the Source/target type so we keep 'object'.
    public static readonly DependencyProperty TargetProperty =
      DependencyProperty.Register("Target", typeof(object), typeof(ExtendedBinding),
      new FrameworkPropertyMetadata()
      {
        BindsTwoWayByDefault = true,
        DefaultUpdateSourceTrigger = UpdateSourceTrigger.PropertyChanged,
      });
    public Object Target
    {
      get { return GetValue(ExtendedBinding.TargetProperty); }
      set { SetValue(ExtendedBinding.TargetProperty, value); }
    }
    #endregion
 
    protected override void OnPropertyChanged(DependencyPropertyChangedEventArgs e)
    {
      base.OnPropertyChanged(e);
      if (e.Property.Name == ExtendedBinding.SourceProperty.Name)
      {
	//no loop wanted
        if (!object.ReferenceEquals(Source, Target))
          Target = Source;
      }
      else if (e.Property.Name == ExtendedBinding.TargetProperty.Name)
      {
	//no loop wanted
        if (!object.ReferenceEquals(Source, Target))
          Source = Target;
      }
    }
 
  }



Shout it kick it on DotNetKicks.com



no comment 3 trackbacks

 

Sync framework - choose your primary keys type carefully

5 March 2010

Do you know the Sync Framework ? This is an amazing framework that enables roaming, sharing of data, and taking data offline !

One usage You can imagine is to sync some local clients databases with a big distant one. Each client taking its data with him and each client was abble to edit/create/delete data. synchKeys

The scenarii where the problem occurs

So where is the problem with the primary keys ? Often, when you design your database you set the types of the primary keys of each row as Int. This integer is when set as autoincremented, and everything works fine for you.

You can't do that with you wants to use the sync framework in bidirectionnal mode. Let me explain why. Imagine this scenario, where we have a database storing apples :

  1. There is 10 apples in your database and each of them is called by it's number
  2. All clients database are synched and client 1 wants to create an apple. He creates one and the apple is so called "Apple 11" : there is only 10 apples in his local database and the autoincrement rule gives him the next available number which is 11,
  3. simultanely client 2 want alsos to create an apple. He creates one and the apple is so called "Apple 11" : there is only 10 apples in his local database and the autoincrement rule gives him the next available number which is also 11,
  4. Both the clients tries to synch with the main database : there is 2" apples 11" __


Newton
What would have said Newton ? This : Auto incrementation does not work in asynchronous scenarii

Actually the data stored would have been really more complex in the real life than apples and each creation of object makes a lot of links which make this problem very complicated to solve.


The solution

As you can see the guilty part of the scenario is the auto-incrementation of the primary key. As we are in an asynchronous scenario, we can't use this pattern to create unique identifiers.Unique identifier is in fact the key of our problem : as pointed out by the MSDN the solution is to use this type instead of auto-incremented integers for the primary keys of your rows. A new value can be generated on your SQL by using NEWID() or NEWSEQUENTIALID() .

Sync framework with bi-directionnal sync ==> Use unique identifier (GUID) instead of auto-incremented integers !

Useful links



Shout it kick it on DotNetKicks.com


no comment 2 trackbacks

 

MVVM - How to integrate the Office Ribbon respecting the pattern (especially the commands)

4 March 2010

Synopsis

The ribbon controls - introduced by office 2007 -are available for free on the Microsoft Office web site (French users should set the language to "english" to access the ressources). They can leverage the user's experience of your application and are pretty simple to use.

When I wanted to add them into one of my application I realized that it was broking the M-V-VM pattern.

In this post, we will see how to use the Ribbon, then what exactly is the issue and finally examine the solution I use as a work-around.

How to use the ribbon

This is very easy, here are the steps :

  • Download the library on the web site (http://msdn.microsoft.com/fr-fr/office/aa973809.aspx),
  • Add a reference to the dll in your project and dclare in the XAML this XML namespace : clr-namespace:Microsoft.Windows.Controls.Ribbon;assembly=RibbonControlsLibrary
  • Then you are free to use the ribbon's controls.


A central part of the Ribbon library is the RibbonCommand. A RibbonCommand is a WPF command plus a lot of things related to how it's presented : a label, a description, an large image, a small image, etc.... Then every button, combobox, checkbox, ... used in the Ribbon use these infos to change the way they are presented. Here is a little example : MVVMRibbonExample

<Window x:Class="MVVMRibbon.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:r="clr-namespace:Microsoft.Windows.Controls.Ribbon;assembly=RibbonControlsLibrary"
    Title="MainWindow" Height="350" Width="525">
 
  <Window.Resources>
    <r:RibbonCommand x:Key="MyFirstCommand" LabelTitle="A command"
        LabelDescription="A command description"
        LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        Executed="RibbonCommand_Executed" CanExecute="RibbonCommand_CanExecute" />
 
    <r:RibbonCommand x:Key="ApplicationMenuCommand"
        LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
        SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg" />
  </Window.Resources>
 
  <DockPanel LastChildFill="True">
    <r:Ribbon DockPanel.Dock="Top">
      <!--I hide the QuickAccessToolBar because I have no use of it-->
      <r:Ribbon.QuickAccessToolBar>
        <r:RibbonQuickAccessToolBar Visibility="Collapsed" />
      </r:Ribbon.QuickAccessToolBar>
 
      <!--Here is the ApplicationMenu : the bubble acting as a main menu in Office-->
      <r:Ribbon.ApplicationMenu>
        <r:RibbonApplicationMenu  Command="{StaticResource ApplicationMenuCommand}" />
      </r:Ribbon.ApplicationMenu>
 
      <!-- And finally the well-know "tabs"-->
      <r:RibbonTab Label="A first tab">
        <!--The controls are grouped in the tabs-->
        <r:RibbonGroup>
          <r:RibbonButton Command="{StaticResource MyFirstCommand}" />
        </r:RibbonGroup>
      </r:RibbonTab>
 
      <r:RibbonTab Label="A second tab"></r:RibbonTab>
    </r:Ribbon>
 
    <FlowDocumentReader />
  </DockPanel>
</Window>


Why using the RibbonCommand is broking the pattern

As you can see in the code above, when you declare the RibbonCommands in the XAML, you have to set a Execute and CanExecute event's handler. These handlers are set in the code behind and this is what breaks the pattern.

Sow why not only declare RibbonCommand inside the viewModels ? Because this will put presentation informations (those inside the RibbonCommand like images, description) inside the ViewModel which one must be decoupled from the way the data is presented.

Actually, only declaring RibbonCommands inside the ViewModel breaks the pattern because it exist a very strong link between the data and how it's presented in these objects.

An another thing is that you can't bind anything to the Ribbon commands because : A 'Binding' cannot be set on the 'XXX' property of type 'RibbonCommand'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject.... Yes, a RibbonCommand is not a DependencyObject.

So I can't use the ribbon ?

Nooooo ! A solutions exists : first you can create some kind of proxies to the command which will make the commands available as a ressource in the views(CommandReference) through binding. Then the view will be responsible to create the RibbonCommands as they which from these commands in the ressources. To this purpose we'll have to extend the standard RibbonCommand to make them accepts a Command as a property.

Ok, ok, I heard your question : why not directy make the extended RibbonCommands acts as a proxy ? The answere is that RibbonCommand does not inherits from DependencyObject and so we can't bind anything on it :-( ! (Which means, by the way, that we can't bind the commands of the viewModels directly to them).

I did not invent this technique, it's from :



The proxy for the commands

As pointed out in this article I call them CommandReference.

We declare a DependencyProperty on which we will bind the command in the ViewModel. As you can see, this class is also a ICommand : all the calls will be translated to the binded command.

public class CommandReference : Freezable, ICommand
{
public static readonly DependencyProperty CommandProperty = 
  DependencyProperty.Register("Command", typeof(ICommand), typeof(CommandReference), 
     new PropertyMetadata(new PropertyChangedCallback(OnCommandChanged)));
public ICommand Command
{
  get { return (ICommand)GetValue(CommandProperty); }
  set { SetValue(CommandProperty, value); }
}
 
#region ICommand Members
public bool CanExecute(object parameter){ 
  return (Command != null) ?Command.CanExecute(parameter):false;
}
 
public void Execute(object parameter){ Command.Execute(parameter);}
 
public event EventHandler CanExecuteChanged;
private static void OnCommandChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
  CommandReference commandRef = d as CommandReference;
  if (commandReference != null)
  {
	ICommand lastCommand = e.OldValue as ICommand;
	if (oldCommand != null) lastCommand .CanExecuteChanged -= commandRef .CanExecuteChanged;
 
	ICommand nextCommand = e.NewValue as ICommand;
	if (newCommand != null) nextCommand .CanExecuteChanged += commandRef .CanExecuteChanged;
  }
}
#endregion
 
#region Freezable
protected override Freezable CreateInstanceCore()
{
  return new CommandReference();
}
#endregion

The extended RibbonCommands

We simply add a ICommand property to the RibbonCommand wich one we will be abble to fill in with a StaticRessource.

public class RibbonCommandExtended : RibbonCommand
{
  private ICommand _command;
  public ICommand Command
  {
    get { return _command; }
    set
    {
      _command = value;
      if (_command != null)
      {
        this.CanExecute += us_CanExecute;
        this.Executed += us_Executed;
      }
      else
      {
        this.CanExecute -= us_CanExecute;
        this.Executed -= us_Executed;
      }
    }
  }
 
  private void us_Executed(object sender, ExecutedRoutedEventArgs e)
  {
    Command.Execute(e.Parameter);
  }
 
  private void us_CanExecute(object sender, CanExecuteRoutedEventArgs e)
  {
    e.CanExecute = Command.CanExecute(e.Parameter);
  }
}


Then, what will my XAML looks like .

Here it is, especially for you, very simple :

<Window.Resources>
  <fwk:CommandReference x:Key="MyCommandReference"
      Command="{Binding MyViewModelCommand}" />
  <fwk:RibbonCommandExtended x:Key="cmd_MyCommand" LabelTitle="A labek"
      LabelDescription="A description"
      Command="{StaticResource MyCommandReference}"
      LargeImageSource="/MVVMRibbon;component/antoine64x64.jpg"
      SmallImageSource="/MVVMRibbon;component/antoine64x64.jpg" />
</Window.Resources>

Then you use the RibbonCommandExtended as you will have used the standard RibbonCommand.

Isn't it a little long to make something pretty simple ? The answer is definitively yes but the Microsoft seems to be working on new version of the ribbon which will respects the M-V-VM pattern...

Why not using our RamoraPattern ?

This is not possible because as I pointed out before, the RibbonCommands are not DependencyObject and so we can't attach properties to them :-( !



Links

Here are some links you may find interesting on the same subjects :


Shout it kick it on DotNetKicks.com



9 comments 3 trackbacks

 

DependencyProperties or INotifyPropertyChanged ?

1 March 2010

When you want to make an object binding-aware you have two choices : implement INotifyPropertyChanged or create DependencyProperties. Which one is the best ? Let's try to answer this question !


How to implement INotifyPropertyChanged

Declaring that your class is implementing INotifyPropertyChanged adds an PropertyChangedEventHandler that you raise for every changes of the properties. We also add a little tricky method checkIfPropertyNameExists(String propertyName) which checks by reflection when debugging if the property name really exists ! You usually ends up with code like this :

/// <summary>
/// Base class for all my viewModel.
/// </summary>
public class ViewModelBase : INotifyPropertyChanged
{
#region INotifyPropertyChanged Members
public event PropertyChangedEventHandler PropertyChanged;
public void FirePropertyChanged(String propertyName)
{
  checkIfPropertyNameExists(propertyName);
  PropertyChangedEventHandler handler = PropertyChanged;
  if (handler != null)
    handler.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
 
#endregion
 
[Conditional("DEBUG")]
private void checkIfPropertyNameExists(String propertyName)
{
  Type type = this.GetType();
  Debug.Assert(
    type.GetProperty(propertyName) != null,
    propertyName + "property does not exist on object of type : " + type.FullName);
}
}


As you can see, the code is quite easy to write and understand. You have to be very vigilant in checking the name of the property you gives as refactoring do not impacts Strings values but it stays quite simple.

DependencyProperties


MSDN definition of a DependencyProperty (link to) : a property that exists on a DependencyObject, is stored by the DependencyObject property store, and is identified by a DependencyProperty identifier on the owning DependencyObject.

Here is an example of how to create a DependencyProperty :

public class MyDependencyObject : System.Windows.DependencyObject
{
 public static readonly System.Windows.DependencyProperty MyDependencyPropertyProperty =
  System.Windows.DependencyProperty.Register("MyDependencyProperty", typeof(String), typeof(MyDependencyObject));
 
 public String MyDependencyProperty
 {
   get { return (String)GetValue(MyDependencyObject.MyDependencyPropertyProperty); }
   set { SetValue(MyDependencyObject.MyDependencyPropertyProperty, value); }
 }
}



Which one choose ?

Performances

All the tests are done under the .NET framework 4.0 with VisualStudio 2010 and .NET Memory Profiler 3.5.
The tests were already done on this page MVVM – Lambda vs INotifyPropertyChanged vs DependencyObject but I do not get the same results...

Execution times

To tests this I created a simple application and two textblocks binded to two String on my ViewModel. The tests were performed one by one and I took care to remove the inheritance of my ViewModel from DependencyObject when testing the INotifyPropertyChanged.

The code used to tests DependencyProperty is this one :

public static readonly DependencyProperty StringWithDependencyPropertyProperty =
DependencyProperty.Register("StringWithDependencyProperty", typeof(String), typeof(MainViewModel));
public String StringWithDependencyProperty
{
  get { return (String)GetValue(MainViewModel.StringWithDependencyPropertyProperty); }
  set { SetValue(MainViewModel.StringWithDependencyPropertyProperty, value); }
}
...
DateTime start = DateTime.Now;
for (int i = 0; i < 100000; i++)
  _mainViewModel.StringWithDependencyProperty = i.ToString();
DateTime end = DateTime.Now;
Console.WriteLine("Total time for DependencyProperty : " + (end - start).TotalMilliseconds +" ms.");


The code used to tests INotifyPropertyChangedis this one :

public String StringWithINotifyPropertyChanged
{
 get { return _stringWithINotifyPropertyChanged; }
 set
  {
    _stringWithINotifyPropertyChanged = value;
    firePropertyChanged("StringWithINotifyPropertyChanged");
  }
}
...
DateTime start = DateTime.Now;
for (int i = 0; i < 100000; i++)
  _mainViewModel.StringWithINotifyPropertyChanged = i.ToString();
DateTime end = DateTime.Now;
Console.WriteLine("Total time for INotifyPropertyChanged : " + (end - start).TotalMilliseconds+" ms.");


The results, for NO binding of the properties, were these :

Total time for DependencyProperty : 45 ms.
Total time for INotifyPropertyChanged : 171 ms.

The results, for one binding of the properties, were these :

Total time for DependencyProperty : 489 ms.
Total time for INotifyPropertyChanged : 1125 ms.

The results, for twelve binding of the properties, were these :

Total time for DependencyProperty : 3600ms.
Total time for INotifyPropertyChanged : 8375 ms.

DPvsInotifyPropertyChangedExecTimeChart
==> DependencyProperty is 2,30 times faster than INotifyPropertyChanged for one binding and this number does not increase with the number of binded controls.!

Edit : as argued in the comments on codeProject and even if it is not the most common way to use INotifyPropertyChanged , I have made the tests with a static event args, and the results are :

Total time for no binding: 154ms
Total time for one binding: 770ms
Total time for twelve bindings: 5605ms

==> DependencyProperies are still better, even if it's less...

Memory usage

I executed the same code and profiled the memory usages :

DependencyProperty created 600 new instances and add 44,583 bytes INotifyPropertyChanged created 876 new instances and add 63,536 bytes

DPvsInotifyPropertyChangedMemoryUsageChart
==> DependencyProperty seems (in my tests) to create less instance and to use less memory than the INotifyPropertyChanged system...

Inheritance issues

To create a DependencyProperty your objects needs to inherit from DependencyObject. This is not always possible and then using INotifyPropertyChanged is the only way to make it Bindable-aware.

Also, by being a DependencyObject, your object will carry with it all the dependency engine stuff and these limitations:


Inheritance from a base class you do not have a grip on ?=> No DependencyProperty !

Animations

Using DependencyProperty make the poperties animatable. If you want to animate a property, there is no simple work-around because, as the MSDN says : In order to be animated, the animation's target property must be a dependency property.

If you can't use DependencyProperty (when you do not create the objects for example), there is still work-arounds techniques.

Flexibility

Using INotifyPropertyChanged is sometimes more flexible than using DependencyProperty. Let me explain that. When you build a screen on which a lot of controls visibility dependsof some rules, you may declare a boolean which value is computed from other boolean.

For example, IsEditionPosible must be set to true only if IsAlreadyInEditionMode = false and if UserHasEditionRights = true. So when changing the value of IsAlreadyInEditionMode or UserHasEditionRights you must tells the binding engine that IsEditionPosible has been updated too. It's easier to do this with INotifyPropertyChanged than with the DependencyProperty with which you should have to create a method, which recalculate and reassign the new value to IsEditionPosible . Here you just have to use this little snippet :

public Boolean IsAlreadyInEditionMode 
{
 get { return _isAlreadyInEditionMode ; }
 set
  {
    _isAlreadyInEditionMode = value;
    firePropertyChanged("IsAlreadyInEditionMode ");
    firePropertyChanged("IsEditionPosible");
  }
}
 
public Boolean UserHasEditionRights 
{
 get { return _userHasEditionRights ; }
 set
  {
    _userHasEditionRights = value;
    firePropertyChanged("UserHasEditionRights");
    firePropertyChanged("IsEditionPosible");
  }
}
 
public Boolean IsEditionPosible
{
 get { return UserHasEditionRights && !IsAlreadyInEditionMode  ; }
}


Note that this is the way that I create computed value for easier binding in my viewModel but this is a subject where improvments may be done...

Flexibility (easier code writing) needed ?=> Choose INotifyPropertyChanged !

Testing

When you performs testing on your object, you will be in trouble if you use DependencyObject : the test are not done on the same thread that created the object and then throws you a "System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it".

Testing => No DependencyProperty !

Code Readability/writing

Some people argues that the use of DependencyProperties the code extremely ugly. I myself think that this is exaclty the same. To make easier the creation of dependencyProperty you can use this snippet : link to the snippet


Links of articles on the same subject :



Shout it kick it on DotNetKicks.com


no comment 2 trackbacks

 

WPF - catch events even if they are already handled

19 February 2010

As you may actually know WPF introduced the routed events. These last are no more specific to a single control but they are routed inside the tree of your controls.

If you want to stop an event, you can mark it as Handled. If so, the routing engine will stop to propage it. In fact this is just an illusion because the engine will only stop leveraging your handlers.

But sometimes, for example when you are using a control from third parties, you want to catch the events even if marked as handled. Here is the little piece of code to use :

anyUIElement.AddHandler(
    UIElement.MouseEnterEvent,
    (RoutedEventHandler)OnMouseEnterCallMeAlways,
    true
    );


This method can be called on any UIElement, in code only. The important part here is the Boolean (true) which tells the engine to call the handle even if the events is marked as handled.


Shout it kick it on DotNetKicks.com

one comment 5 trackbacks