Waldo Codes

Pragmatic insights on software craftsmanship and other topics.

The WPF data grid has a property that controls the how headers get handled when copied. ClipboardCopyMode, can be set it to “IncludeHeader” or “ExcludeHeader” which is the default. There is the possibility the grid can exclude the header even in IncludeHeader mode. Let me explain.

The data grid header is customizable. It can use a header template object to place whatever you can imagine into the header. Imagine you want dancing clown gifs in the header of the grid. In WPF you can do that. Beware though, this is the condition that breaks IncludeHeader mode. Your dancing clowns won't make it to the clipboard.

For my example the header template includes a unit of measure displayed next to the column name. The user can change the unit of measure so this can't be a static value. The XAML markup looks like this.

 <UserControl.Resources>  
     <DataTemplate x:Key="FlowRate" DataType="DataGridColumnHeader">  
       <TextBlock Text="{Binding Source={x:Static units:UnitsContext.CurrentSymbols}, Path=FlowUnit, StringFormat=Flow-Rate ({0})}" />  
     </DataTemplate>  
     <DataTemplate x:Key="Pressure" DataType="DataGridColumnHeader">  
       <TextBlock Text="{Binding Source={x:Static units:UnitsContext.CurrentSymbols}, Path=PressureUnit, StringFormat=Pressure ({0})}" />  
     </DataTemplate>  
</UserControl.Resources>  

This creates a header in the table that looks like this. | Flow-Rated (BPD) | Pressure (psi) |

The issue is if we copy/paste from the grid into Excel we get this. | | |

The fix for this is actually relatively simple. The required text needs to get from the header template back up to the data grid. To do this we can use an attached property.

/// <summary>  
/// This attached property works with a header template that includes one TextBlock. Text content from the templates TextBlock is copied to the  
/// column header for the clipboard to grab.
/// </summary>  
   public static class TemplatedDataGridHeaderText {  
     private static readonly Type OwnerType = typeof(TemplatedDataGridHeaderText);  
     public static readonly DependencyProperty UseTextFromTemplateProperty = DependencyProperty.RegisterAttached("UseTextFromTemplate", typeof(bool), OwnerType, new PropertyMetadata(false, OnHeaderTextChanged));  
     public static bool GetUseTextFromTemplate(DependencyObject obj) {  
       return (bool)obj.GetValue(UseTextFromTemplateProperty);  
     }  
     public static void SetUseTextFromTemplate(DependencyObject obj, bool value) {  
       obj.SetValue(UseTextFromTemplateProperty, value);  
     }  
     private static void OnHeaderTextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) {  
       var textColumn = d as DataGridTextColumn;  
       if (textColumn == null) return;  
       if (textColumn.HeaderTemplate == null) return;  
       var headerTemplateTexblockText = textColumn.HeaderTemplate.LoadContent().GetValue(TextBlock.TextProperty).ToString();  
       textColumn.Header = headerTemplateTexblockText;  
     }  
   }  

In XAML this attached property can now be used to ensure the header text will make its way to the clipboard.

<DataGrid ItemsSource="{Binding }" AutoGenerateColumns="False" IsReadOnly="True" VerticalScrollBarVisibility="Auto" VerticalAlignment="Stretch">  
     <DataGrid.Columns>  
       <DataGridTextColumn Binding="{Binding FlowRate.UserValue, StringFormat=N3}" HeaderTemplate="{StaticResource FlowRate}"  
            attachedProperties:TemplatedDataGridHeaderText.UseTextFromTemplate="True"/>  
       <DataGridTextColumn Binding="{Binding Pressure.UserValue, StringFormat=N3}" HeaderTemplate="{StaticResource Pressure}"  
                 attachedProperties:TemplatedDataGridHeaderText.UseTextFromTemplate="True"/>  
     </DataGrid.Columns>  
</DataGrid>  

This is just one approach for solving this issue. Another might be to directly set the header text through an attached property.

Reference equality is the default comparator for objects in .Net, but it is seldom what I want when coding. More often I want to know if objects are the same based on the state they contain. Changing object equality comparison is as easy as overriding the Equals method. Yet, when you are using LINQ extension methods such as Distinct() or Contains() there are a few things to be aware of.

In Domain Driven Design (DDD) the value object pattern is frequently used.. Value objects in DDD don't need their own identity. They are identified by the uniqueness of all the information they contain. For example consider an Address object that has several fields (Street, City, State, Zip). No address is the same as another, unless all the field values are equal.

Imagine that we have a list of customer addresses and we want to return only the unique addresses.

 var addresses = new List<Address>() {
      Address = new Address("102 Birch", "Spring", "TX", 77777),
      Address = new Address("304 Elm", "Newport", "MA", 33234),
      Address =  new Address("102 Birch", "Spring", "TX", 77777)
};

var uniqueAddresses = addresses.Distinct();

Distinct calls the GenericEqualityComparer. This in turn uses the Equals & GetHashCode methods on the objects in the collection. GetHashCode is called to determine possible equality. Equals is called to determine absolute equality. Overriding GetHashCode is important in making the Distinct method work with the GenericEqualityComparer. If you fail to override GetHashCode, you will find the Distinct method does not work right. If LINQ collection extensions aren't working as expected this is likely the cause.

Guidelines for Object Equality & Hash Codes – If you have two objects considered equal then they should return the same hash. – Hash codes on mutable objects should be calculated off immutable fields. This keeps the hash the same through the object lifetime. – If you are using LINQ methods be sure that your objects aren't mutating and causing a hash code change. If for whatever reason you need to mutate objects in a collection, consider returning 1 as the hash. Caution: this will have a performance impact.

For a more in-depth look at all the things to consider, checkout this post by Eric Lippert.

A few more things to think about... LINQ collection extensions that do comparison allow passing in a EqualityComparer function. This is great as long as you control all the places in code where you need comparison. Beware of third party APIs that may have calls that would use the GenericEqualityComparer. Also, if you override equals, you may want to seal you class. This will prevent inherited classes from creating an incorrect Equals implementation. Lastly, override the equality (==) and inequality operators (!=) to avoid accidental comparison bugs.

EventAggregator is the Prism incarnation of the publish-subscribe pattern. Message classes are sent between components, keeping the components decoupled.

Writing unit tests against the Prism EventAggregator using Moq should be easy right? The IEventAggregator interface is provided by the Prism framework. We know interfaces make things testable. So yes this all should be possible. However, there is a good deal of confusion around this.

StackOverflow: Moq Event Aggregator is it possible? StackOverflow: Mocking Prism Event Aggregator using moq for unit testing StackOverflow: How to verify event subscribed using moq?

It's not as confusing or complex as confusion can make it :)

Imagine you have a subscription to an event, and the Action in the Subscribe() method is private. Using Moq the event needs to be published and the system under test needs to be examined for a state change.

[TestMethod]
public void EventAggregator_ReceivesUpdatedUnitsEvent_CallsOnUnitsUpdated(){  

  //Arrange  
  //Use the real event not a mock  
  _updateUnitsEvent = new UpdatedUnitsEvent(); 
  //Setup the mock EventAggregator to return the event  
  _mockEventAggregator.Setup(x => x.GetEvent<UpdatedUnitsEvent>())
                      .Returns(_updateUnitsEvent);    
  _mockUnits.Object.DensitySolid = DensitySolidSymbols.KgCm3; 

  //Act   
  //Trigger the event by publishing our payload   
  _updateUnitsEvent.Publish(_mockUnits.Object); 

  //Assert   
  _mockEventAggregator.Verify(x => x.GetEvent<UpdatedUnitsEvent>(), 
  Times.Once); 
  //Verify using Moq   
  var vm = _materialMasterVm.MaterialModels.Current as MaterialViewModel;
  //Check State 
  Assert.AreEqual(DensitySolidSymbols.KgCm3, vm.Density.UserUnitType); 
}  

Don't make the mistake of trying to use a mock for the message class.

Happy Coding!

This took place back in the days before Git became the standard for source control. Back then people used zip files saved into folders on the desktop. The wiser folks used centralized source control. The wild and crazy used some new thing called Git.

At work I had was tasked with setting up our source control. I went online and searched till I found a online provider offering SVN hosting. And that was the end of it. Years worth of work went into our cloud hosted SVN repos.

One morning I walked into work got my coffee sat down to pull the latest code from our SVN repository. My request returned with an error. At work the internet was coming over a 1mb line so it could be a little iffy. I tried again. Another error. Going down the rabbit hole I ended up going to the our SVN providers website.

I don't remember the exact wording but the message on the website read something like this...

“We are sorry to inform you that 'Acme SVN Hosting' is no longer in business. Our Amazon server was hacked because we used a weak password. The hacker demanded a ransom. We chose to not pay so we are out of business effective today. Sorry about your code, we hope you have a local copy”

Pretty basic mistake weak password. A tragic tale. They were out of business and we were no longer customers. Thankfully, we did have recent local copies and were able to piece things back together.

The easiest thing would have been to find another SVN provider and to continue using SVN. Instead I decided it would be a good time to switch source control. We moved over to TFS on Azure. Needless to say many pains were ahead of us. Looking back it is sad because Git was very mature by this time. This story makes the case for distributed source control. Why

Happy Coding!

Prism documentation is thorough. However, that makes it lack a certain conciseness that makes it easily digestible. One key thing that you will want to understand is how to get your views and view models connected. This post will quickly detail how to make it all work.

View Model Locator Configuration If your view model has a default constructor, it will be instantiated and matched to the view automatically. If your view models do anything interesting, they will likely not have default constructors. You will need to configure the view model locater to resolve constructor dependencies from your IOC container.

ViewModelLocationProvider.SetDefaultViewModelFactory(
    t => container.Resolve(t)
);

View to view model wiring is based on convention. They are match based on name, much like the familiar MVC conventions. Be careful though, if your views are suffixed with “view”, it will not work.

✅ Do this ViewModels.MyScenicViewModel – Views.MyScenic ❌ Don't do this ViewModels.MyScenicViewModel – Views.MyScenicView

The convention can be overridden with the following configuration point.

ViewModelLocationProvider.SetDefaultViewTypeToViewModelTypeResolver(
(viewType) => {
    ...
    return viewModelType;
});

View Specific Wire up Your view must implement the IView marker interface found in the Microsoft.Practices.Prism.Mvvm namespace.

public partial class Wizard : Window, IView {
    public Wizard() {
        InitializeComponent();
    }
}

And finally don't forget to set the auto wire up flag to true in your view.

<Window x:Class="MyProject.Views.Wizard"   
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 xmlns:mvvm="clr-namespace:Microsoft.Practices.Prism.Mvvm;
 assembly=Microsoft.Practices.Prism.Mvvm.Desktop"
 Title="Wizard" Height="600" Width="800"
 mvvm:ViewModelLocator.AutoWireViewModel="True">

For a more in-depth read, check the Prism 5.0 Developers Guide.

I was listening to .Net Rocks! show 971 with Brian Noyes, and I was glad to hear that Microsoft dropped a new release of Prism – v5.0 for WPF. I have been using the Prism framework on a large application. It allows me to easily break the application into modules. For applications that need more than the simple MVVM support offered by frameworks like MVVM Light, it is a solid choice. All the code is on CodePlex. Here are the highlights of what is new in v5.0 – Broken into smaller more targeted assemblies – Updated NotificationObject to BindableBase – Includes a conventions-based View-Model Locator – Objects can be used to pass data around in Region Navigation

The Haters These are all great updates. Sadly, reading comments on CodePlex would make you think otherwise. Most comments are negative, directed at the complexity and learning curve of the Prism framework. Other comments seem like people blowing off steam about issues in WPF. Normally, I wouldn't pay much attention to comments of this nature. However, it struck me as odd that people have such backlash at technologies that are a clear improvement on previous generations.

For anyone discouraged by the complexity of Prism or WPF in general. Do not lose sight of what the patterns and frameworks surrounding WPF allow you to do. Ultimately, they are allowing you to write testable decoupled code. Be willing to embrace the pain that may be pushing you toward the pit of success.

Microsoft, thanks for the Prism Update! Happy Coding!

While working on a large .Net API, I ran into an interesting issue. The codebase was exposing functions in classes that were not necessary for the public API. Originally, this was done to facilitate testing. Several of the classes had methods involving complex calculations. It was easiest to test these in isolation. The code had top level functions that would call several other calculation functions. The result was a testable cluttered API.

While this was not an issue when we used our own API, it was a point of confusion for third parties using our API. There are two lines of thinking one could take.

Test Centric With this approach you justify your design by saying that it is more important to write the code to be testable than it is to worry about hiding a few methods.

Design Centric In this line of thinking you must put the importance of the design beyond that of tests. Testing is important, but it should not drive the design. For example, this approach shuns adding public properties to exam the internals of a class solely for the purpose of testing.

I decided to take a design centric approach. Modifying many access modifiers to internal, I soon had the API cleaned up. Using intellisense in Visual Studio showed a concise list of functions and methods. Utilizing our API would be straightforward and simple.

At this point I realized I needed to address all my failing unit tests. Now that the access modifiers were set to internal, the test harness was unable to see the methods being tested.

The code could have been refactored to pull out a small calculation engine. This then could then act as an internal member of the higher-level classes that comprised the API surface area. This would achieve the goal of making the code testable, while at least keeping the primary API classes clean. However, API users would still see the additional calculation class. The only true way to keep the users out of the lower-level code is to mark it as internal.

As it turns out there is a pragmatic solution to the issue.

In the project AssemblyInfo file add an attribute to expose the internal classes to your testing assembly.

Here is an example with VB attributes...

Exposing the assemblies to Test Framework, and to Moq's Proxy Generating Assembly

<Assembly: InternalsVisibleTo("Company.Library.Calculations.Test")> 
<Assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")>

Notice that I also expose to DynamicProxyGenAssembly2, this is so Moq's proxy engine can still create mocks for internal classes as well.

This works well. It’s a minimal pain, and allows us to hand our third party implementers a very clean API.

When working in WPF the typical property changed notification typically looks something like this…

public bool IsBusy {
  get { return _isBusy; }
  set {
    if (value.Equals(_isBusy)) return;
    _isBusy = value;
    RaisePropertyChanged("IsBusy");
  }
}
private bool _isBusy;

The issue with this is that it uses a magic string and is not particularly refactor friendly. It can be easily improved by using a lambda expression. This gets us the refactor friendliness, but it still is a little ugly.

public bool IsBusy {
  get { return _isBusy; }
  set {
    if (value.Equals(_isBusy)) return;
    _isBusy = value;
    RaisePropertyChanged(() => IsBusy);
  }
}
private bool _isBusy;

The best case would be to not need to raise property changed at all. This is not going to happen, so how about a second best? What if we could just raise property changed without needing to specify the property name at all?

public bool IsBusy {
  get { return _isBusy; }
  set {
    if (value.Equals(_isBusy)) return;
    _isBusy = value;
    NotifyChanged();
  }
}
private bool _isBusy;

With .Net 4.5 and above, this is now possible. Here is a basic implementation of ObservableObject with the new .Net 4.5 CallerMemberName attribute.

/// <summary> Base observable object class. </summary>
public abstract class ObservableObject : INotifyPropertyChanged {

  public event PropertyChangedEventHandler PropertyChanged;
  public delegate void PropertyChangedEventHandler(object sender, PropertyChangedEventArgs e);

  /// <summary> Notify property has changed </summary>
  /// <param name="propertyName">String property name, if not 
  provided, will be picked up from calling member</param>
  protected void NotifyPropertyChanged([CallerMemberName] string propertyName = "") {
  if (PropertyChanged != null){
    PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Happy Coding!

Recently I discovered that NuGet package restore has been dramatically simplified.

The NuGet team has provided the following document Migrating to Automatic Package Restore.

I will provide the abbreviated form of that document here.

The Previous Method Right click on your solution in visual studio choosing >> Enable package restore. This created a .NuGet folder containing the nuget.exe etc. Your .csproj or .vbproj files were modified with an tag containing a NuGet path.

This triggered automatic package restore upon a build of your solution. Thankfully, this is no longer necessary!

The New Method You do nothing. Unless you are building from the command line. If so simply run 'NuGet restore' before the rest of your build.

Enter your email to subscribe to updates.