The latest TLA (Three Letter Acronyms) du jour seem to be SoC, DI, and IoC.  What do these stand for and why should you care about them?

Consider the following (very) simple console application:

Code Snippet
  1. using System;
  3. namespace TightlyBoundTestApp
  4. {
  5.     public class Program
  6.     {
  7.         static void Main(string[] args)
  8.         {
  9.             // Load up a customer
  10.             Customer c = new Customer();
  12.             // Logging should have written a message
  13.             c.Log();
  15.             Console.ReadKey();
  16.         }
  17.     }
  19.     public class Customer
  20.     {
  21.         private Logger logger;
  23.         public Customer()
  24.         {
  25.             logger = new Logger();
  26.         }
  28.         public void Log()
  29.         {
  30.             logger.LogMessage("This should be logged");
  31.         }
  32.     }
  34.     public class Logger
  35.     {
  36.         public void LogMessage(string message)
  37.         {
  38.             Console.WriteLine("Log: " + message);
  39.         }
  40.     }
  41. }

In this sample application, we have a Customer class which (for example purposes) only has a single method: Log, which allows it to log a message. We might use this to keep track of the transactions done by a customer so we have an audit trail for example. The logging happens by calling the LogMessage method on an instance of the Logger class which the Customer class created in its constructor.

In our entry point to the program, we create a new instance of our Customer class, and tell it to log a message.  If we run this, a log message will be printed to the console, then the program will exit once we press a key.

So, it all works okay, but there a few problems which may cause issues for us down the track.  We have made our Customer class depend on our Logger class.  What happens when we want to create unit tests for our Customer class?  We would also have to consider our Logger class as they are tightly coupled.

Read the rest of this entry »

Tim Heuer wrote glowingly about Josh Smith’s new book ‘Advanced MVVM‘ on his blog recently (, so I decided to check it out.

I was reading through the comments, and saw that Josh recommended checking out an article on MSDN he’d written in Feb 2009 entitled: "WPF Apps With The Model-View-ViewModel Design Pattern" and get a firm grounding in that before moving on to his new book. This seemed like a good idea, so I decided I’d try migrating the WPF example app in the article over to Silverlight 4 as a way of trying out some of the new features like support for Commands, IDataErrorInfo support, etc.

In line with the Pareto principle, most of the migration went very smoothly and swiftly and then there were a few snags which ended up taking the bulk of the time to resolve. I’ve outlined these issues and their resolutions below in the hope that it helps someone doing something similar in future. The full completed Silverlight 4 solution is also included at the bottom of the post.


Silverlight version vs WPF version
Silverlight version vs WPF version

Read the rest of this entry »

Here’s a sample page using the AutoScalingTextBlock referred to in the previous post (An Auto Scaling TextBlock for Silverlight).

Use the GridSplitter controls (grey lines) at the right and bottom of the grid to change the size of the TextBlocks and see the font size change up and down, depending on the ‘ScalingMode’ setting of each AutoScalingTextBlock, or resize the page to also see it in action.

Read the rest of this entry »

During a recent Silverlight project which required extensive localisations into eight different European languages, I discovered just how much text length can vary between cultures. This caused a couple of issues where there was a limited area for a specific piece of text to fit within, which would look fine in English, but then would not fit in a different language and would be cut off.

I thought this would be a good idea for a custom control, and so have written an AutoScalingTextBlock control.

It’s a simple text control (based on ‘ContentControl’) that shrinks or expands the font of the text to display all of the text in the preferred size of the TextBlock. See it in action:

While deciding how to get started, I came across an excellent TextTrimming TextBlock on Robby Ingebretsen’s site: which I used as a basis, and so am releasing my control under the same MIT license that he used. I hope it comes in handy for someone.


Dependency Properties:

  • MinFontSize: This is the smallest size the font will be reduced to. Defaults to 8pt.
  • MaxFontSize: This is the largest size the font will be increased to. Defaults to 20.
  • ScalingMode: This controls if the font size should be scaled only up, or down, or both ways to fit the text within the boundaries of the textbox.  Defaults to BothWays.
  • StepSize: This is the point size the font will be increased or decreased by each iteration until the text fits the desired size. Higher amounts will require fewer iterations, so will be faster, but the changes will be more abrupt. Defaults to 0.5.

Download the control: AutoScalingTextBlock.cs or a sample solution with examples in the Page.xaml file:  Free to use under the MIT licence.

kick it on