Archive

Archive for 2009

Format WPF Bindings With Resource File Lookups

March 21st, 2009
3 comments

This post explains a pattern that combines Data Binding, the new StringFormat property and resource lookups through the application of a custom MarkupExtension.

 

StringFormat

Microsoft introduced the StringFormat property with SP1 for .NET 3.5. StringFormat often eliminates the need for a custom converter if you just need to format a bound value.
Here’s a very simple sample that displays hello xxx on the screen (where “xxx” is the value entered in a TextBox control:

 

<TextBox
    x:Name="name"
    Text="world" />

<TextBlock
    Text="{Binding ElementName=name,
                   Path=Text,
                   StringFormat=hello {0}}" />

 

Resource Files

I often use resource files to store strings – not only for localization tasks but also in order to maintain strings that are intended for users at a central place. My resource strings often contain placeholders which are populated at runtime using String.Format:

 

image

 

//use resource file to create message
var msg = Resources.Ask_Whether_To_Connect_To_New_Share;
msg = String.Format(msg, configuration.Name);

//display dialog
MessageBoxResult doConnect = Dialogs.ShowYesNo(msg);

 

 

Bringing Bindings and Resource Files Together

In the sample above, I accessed the resource file programmatically. In XAML however, I prefer a declarative approach. In order to get there, I implemented a simple MarkupExtension that allows me to do just that:

 

<!-- Display a formatted text -->
<TextBlock
  x:Name="Title"
  Text="{Binding Path=Name,
                 StringFormat={ext:Resource Ask_Whether_To_Connect_To_New_Share}}"
 />

 

The above snippet results in a formatted text being displayed:

image

 

Resource MarkupExtension

Here’s the markup extension. As you can see, it’s fairly trivial. Do note that the reference to the application’s Resources file is hardcoded – you will have to set a using statement or adjust that line in order to use your custom resource file.

 

/// <summary>
/// A markup extension that provides simple access to a given
/// entry in the application's <see cref="Resources"/> file.
/// </summary>
public class Resource : MarkupExtension
{
  /// <summary>
  /// The resource key to be used for the lookup.
  /// </summary>
  public string ResourceKey { get; set; }


  /// <summary>
  /// Inits the <see cref="Resource"/> markup extension
  /// with the key to be assigned.
  /// </summary>
  /// <param name="resourceKey">The resource key to be assigned.</param>
  public Resource(string resourceKey)
  {
    ResourceKey = resourceKey;
  }


  /// <summary>
  /// Performs a lookup for the defined <see cref="ResourceKey"/>.
  /// </summary>
  /// <returns>
  /// The value of the resource that is specified by the
  /// <see cref="ResourceKey"/> property. If the property is not
  /// set, a null reference is returned.
  /// </returns>
  public override object ProvideValue(IServiceProvider serviceProvider)
  {
    if (String.IsNullOrEmpty(ResourceKey)) return null;
    return Resources.ResourceManager.GetObject(ResourceKey);
  }
}

 

Enjoy 🙂

Author: Categories: WPF Tags: ,

Simplify Time Measurement in Tests and Debug Code

February 23rd, 2009
5 comments

A simple helper class I derived from a more generic pattern: For debugging and testing, I quite often want to measure the time used for a given process. Usually, this looks somewhat like this:

 

public void TestElapsedTime()
{
  DateTime start = DateTime.Now;

  //do some work

  DateTime end = DateTime.Now;
  double elapsedTime = end.Subtract(start).TotalMilliseconds;
  Console.Out.WriteLine("Work took {0} milliseconds", elapsedTime);
}

 

However: The code above, while being pretty simple, can be easily wrapped into a generic helper class:

 

/// <summary>
/// A guard that can be used to measure the time
/// used for a given process by simply wrapping it
/// in a using statement.
/// </summary>
public class TimeGuard : IDisposable
{
  private readonly Action<double> action;
  private readonly DateTime startTime;


  /// <summary>
  /// Creates the guard with a given action that receives the
  /// elapsed time in milliseconds.
  /// </summary>
  /// <param name="setDelta">The action that is being invoked
  /// with time (in milleconds) that was taken between construction
  /// of this instance until disposal.</param>
  /// <exception cref="ArgumentNullException">If <paramref name="setDelta"/>
  /// is a null reference.</exception>
  public TimeGuard(Action<double> setDelta)
  {
    if (setDelta == null) throw new ArgumentNullException("setDelta");
    
    action = setDelta;
    startTime = DateTime.Now;
  }


  /// <summary>
  /// Calculates the elapsed time since construction
  /// and submits the delta to the <see cref="action"/>
  /// action.
  /// </summary>
  public void Dispose()
  {
    var now = DateTime.Now;
    action(now.Subtract(startTime).TotalMilliseconds);
  }
}

 

Using the TimeGuard class, I can perform time measurements without having to deal with DateTime instances and the calculation of the elapsed time at all. Two samples:

 

public void TestElapsedTime()
{
  double elapsedTime = 0;
  using (new TimeGuard(t => elapsedTime = t))
  {
    //do some work
  }

  Console.Out.WriteLine("Work took {0} milliseconds", elapsedTime);
}

 

[Test]
public void TestElapsedTime()
{
  using (new TimeGuard(t => Assert.Less(t, 500)))
  {
    //do some work here that should take less than 500 ms
  }
}

 

Apart from providing cleaner code, I also prefer this approach because it encapsulates time measurement functionality in a single class and simplifies adjustments, like using a different pattern to retrieve time stamps, or using the StopWatch class to get a more accurate measurement (thanks to Simone Chiaretta for the hint).

Author: Categories: C#, Testing Tags:

Simple Extension Method to Evaluate Listings For a Match

February 4th, 2009
2 comments

I’m currently dealing with a system that switches between different states, which require evaluations that look similar to the snippet below:

 

//check status flags
TestStatus status = GetStatus();
if (status == TestStatus.Preparing ||
    status == TestStatus.Running ||
    status == TestStatus.PostDelay)
{
  ...
}

 

Given the fact that I’m having lots of states, I had to produce pretty nasty code, so I wrote that handy little extension method that takes care of the issue once and for all:

Edit (2009.02.08): Returning false for null values which allows to submit null references without exception.

 

/// <summary>
/// Checks a list of candidates for equality to a given
/// reference value.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="value">The evaluated value.</param>
/// <param name="candidates">A liste of possible values that are
/// regarded valid.</param>
/// <returns>True if one of the submitted <paramref name="candidates"/>
/// matches the evaluated value. If the <paramref name="candidates"/>
/// parameter itself is null, too, the method returns false as well,
/// which allows to check with null values, too.</returns>
/// <exception cref="ArgumentNullException">If <paramref name="candidates"/>
/// is a null reference.</exception>
public static bool Is<T>(this T value, params T[] candidates)
{
  if (candidates == null) return false;

  foreach (var t in candidates)
  {
    if (value.Equals(t)) return true;
  }

  return false;
}

 

Using this “Is” extension, I can now write the above code like this:

 

if (status.Is(TestStatus.Preparing, TestStatus.Running, TestStatus.PostDelay)
{
  ...
}

 

Of course, this is not limited to Enums but works with everything that supports the Equals operator:

string name = ...
if (name.Is("foo", "bar"))
{
  //foobar!
}
Author: Categories: C# Tags:

First Anniversary

January 16th, 2009
No comments

Wow, already a year since my first blog post! It’s been fun and I’m far from running out of ideas – stay tuned 🙂

Author: Categories: Uncategorized Tags:

ComboBox SelectedItem and ItemsSource: Order Matters

January 14th, 2009
8 comments

A co-worker of mine had a strange issue with a bound combo box that looked like this:  

<ComboBox
  x:Name="cboParentUser"
  ItemsSource="{Binding Path=Order.Store.Users, ElementName=me, Mode=Default}"
  SelectedItem="{Binding Path=Order.ParentUser, ElementName=me, Mode=Default}"
  IsEditable="False"
  DisplayMemberPath="UserName" />

 

As we could observe at runtime, selecting an item in the combo box properly updated the underlying ParentUser property. Furthermore, we could easily exchange the data context (Order dependency property) in order to edit different items.

However: As soon a the editor control that contained the combo box was unloaded, the ParentUser property of the currently edited Order was set to null, so all previously made adjustments were lost.

The reason behind this behavior seems to be the fact that both ItemsSource and SelectedItem are bound to the same dependency property: Apparently, when Order is set to null during unloading, WPF realizes that the ItemsSource is no longer valid, and therefore clears the SelectedItem, to which the combo box still appears to hold a reference at this moment – which brings it down to a question of proper coercion. Or maybe not – the reason behind this is not entirely clear to me.

However: Changing the declaration order of SelectedItem and ItemsSource fixes the problem: 

<ComboBox
  x:Name="cboParentUser"
  SelectedItem="{Binding Path=Order.ParentUser, ElementName=me, Mode=Default}"
  ItemsSource="{Binding Path=Order.Store.Users, ElementName=me, Mode=Default}"
  IsEditable="False"
  DisplayMemberPath="UserName" />

 

And yes: This does feel like a dirty hack.

Author: Categories: WPF, WPF Controls Tags: ,

(Enterprise Validation Block, Interfaces) => BIG Trouble

January 8th, 2009
2 comments

I had a first look at Microsoft’s Enterprise Validation Block 4.1 today and trashed it before I even got really started. The reason: The thing doesn’t really support OO-architectures that rely on interfaces / polymorphism.

 

I ran my test with this simple interface / implementation:

public interface IModel
{
  [StringLengthValidator(1, 5, MessageTemplate = "First rule failed.")]
  string First { get; set; }

  [StringLengthValidator(1, 5, MessageTemplate = "Second rule failed.")]
  string Second { get; set; }

  [StringLengthValidator(1, 5, MessageTemplate = "Third rule failed.")]
  string Third { get; set; }
}

public class Model : IModel
{
  public string First { get; set; }

  public string Second { get; set; }

  public string Third { get; set; }
}
 

Now look at this test:

public void Test()
{
  Model model = new Model();

  var result = Validation.Validate(model);
  foreach (var validationResult in result)
  {
    Console.Out.WriteLine(validationResult.Message);
  }
}

 

The code above won’t output a single validation error, because it only checks the Model class for validation attributes. And there are none – the rules have been declared in the IModel interface. My bad.
The code below, on the other hand, works. Notice that the model variable is declared using the interface type:

public void Test()
{
  IModel model = new Model();

  var result = Validation.Validate(model);
  foreach (var validationResult in result)
  {
    Console.Out.WriteLine(validationResult.Message);
  }
}

 

Now, it gets really ugly when you’re having attributes at different places. After this initial test, I moved the third validation rule into the implementing Model class and removed the Third property from the interface:

public interface IModel
{
  [StringLengthValidator(1, 5, MessageTemplate = "First rule failed.")]
  string First { get; set; }

  [StringLengthValidator(1, 5, MessageTemplate = "Second rule failed.")]
  string Second { get; set; }
}

public class Model : IModel
{
  public string First { get; set; }

  public string Second { get; set; }

  [StringLengthValidator(1, 5, MessageTemplate = "Third rule failed.")]
  public string Third { get; set; }
}

 

As a result, validating for the IModel interface returns two validation errors, and validating for the Model class reports a single error for the third rule. Now think about handling scenarios where your class implements several interfaces that may provide validation rules. Ouch.

 

Support for inheritance was the absolute first thing I tested. Frankly, it is beyond me how this library could make it into production over a year ago with this kind of behavior.

This not only promotes bad design, it’s also dangerous as hell because refactoring silently breaks your validation.

Author: Categories: C# Tags: