Kent Boogaart

WindowItemsControl

2011-11-19T10:19:00.001Z

The application I'm currently working on - top secret, mum's the word, your death for my indiscretion, you get the idea - includes a widget-style interface. In order to render these widgets, I use an ItemsControl and bind it to a collection of view models, each of which represents a widget. I use a Canvas to lay them out according to their XOffset and YOffset properties. Something like this:

<ItemsControl ItemsSource="{Binding Widgets}">
    <ItemsControl.ItemsPanel>
        <ItemsPanelTemplate>
            <Canvas/>
        </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>
    <ItemsControl.ItemContainerStyle>
        <Style>
            <Setter Property="Canvas.Left" Value="{Binding XOffset}"/>
            <Setter Property="Canvas.Top" Value="{Binding YOffset}"/>
        </Style>
    </ItemsControl.ItemContainerStyle>
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <views:WidgetView/>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

This all works fine and I'd even go so far as to say it's a beautiful thing. However, it is only a widget-style interface by virtue of some trickery on my part. Without said trickery, it would be more of an MDI interface.

With an MDI interface, multiple child windows are contained within a parent window – they cannot appear outside the bounds of the parent. Whilst my widgets look like windows, they aren't. They're just regular WPF user controls with some additional smarts to allow positioning and what-have-you. And whilst it looks like they're free to roam wherever they like on the desktop, they're not. They're all contained within the ItemsControl, which is within the only Window in my application. Thus, they cannot be positioned outside the area in which the Window resides. It just so happens that I've stretched that Window across the entire desktop and made it transparent. This gives the illusion that I have a widget interface and am thus as cool as The Dude himself, but I actually have an MDI interface which makes me more Napolean Dynamite than Lebowski. Before the dance, that is.

All this wouldn't concern me terribly (one learns to live with it) but my users are actually privy to more screen real estate than I. And when I say "more", I mean they have six screens whilst I have two, one of which I can't use for anything of import because it frequently distorts and shows other signs of discontent (no audible screams as yet). Because of this abundance of screen real estate, my Window has to to stretch across a huge expanse of pixels in order to keep up this illusion of cool. This has dire consequences for performance. You see, if one's Window size exceeds the maximum texture size of one's video card (I don't have one of course, but my users do) then the video card won't be able to accelerate rendering of said Window. The Window will be software-rendered instead, which is probably going to be a lot slower and less capable of Dude-worthy effects and animations.

No problem, you say. Just host your widgets inside windows instead and be done with it. And this is indeed what I am going to do.

But I want it to be seamless with respect to the current code base. I don't want to have to go hook up a bunch of event handlers to create/show/close windows when my widget collection changes. I don't want to have to change the way my view models keep track of widget positions and sizes (all persisted across application restarts, of course). All I want to do is change this:

<ItemsControl ItemsSource="{Binding Widgets}">

to this:

<WindowItemsControl ItemsSource="{Binding Widgets}">

But unfortunately WPF doesn't have a WindowItemsControl. Boo. And it doesn't seem as though anyone in the community has written one.

Obviously, then, I set out to write my own.

My initial approach failed, but it's worth discussing anyway. I tried to have my WindowItemsControl create Window instances as containers. This failed because internal WPF code was attempting to add these Windows as visual children of the ItemsControl, and Windows must be top-level visual items (makes sense). So I tried to hack around this because I really wanted the logical connection between the Window and the WindowItemsControl, much the same way there's a logical connection between a ListBoxItem and its containing ListBox. If I could trick WPF into forgoing the visual connection, I could then attempt the logical connection.

Well, I tried all sorts of nastiness, and ended up reflectively invoking an internal member to trick WPF into not including the Window as a visual child. Success! Right!? Alas, no, because when I then added the Window as a logical child of the WindowItemsControl, I got another similar error. I can't remember the details, nor can I explain why a Window cannot be a logical child of another control (it's only a logical connection, after all). But it didn't work and I gave up on this approach entirely.

My second approach is much more sane but gives up on creating a logical connection between the Windows and their host. But I don't really need that anyway – it was a nice-to-have.

What I did instead was had the WindowItemsControl create WindowItemsControlItem instances as containers. These containers are really just surrogates for the Window they represent. When they're initialized, they display the Window. When they're destroyed, they close the Window. In addition, if a Window is closed ahead of time, the corresponding data item is removed from the underlying collection and thus too the surrogate from the visual tree.

The code is actually quite neat and compact. Here is the code for WindowItemsControl:

public class WindowItemsControl : ItemsControl
{
	public static readonly DependencyProperty ShowDialogProperty = DependencyProperty.Register(
		"ShowDialog",
		typeof(bool),
		typeof(WindowItemsControl));

	public static readonly DependencyProperty OwnerProperty = DependencyProperty.Register(
		"Owner",
		typeof(Window),
		typeof(WindowItemsControl),
		new FrameworkPropertyMetadata(OnOwnerChanged));

	public static readonly DependencyProperty WindowStartupLocationProperty = DependencyProperty.Register(
		"WindowStartupLocation",
		typeof(WindowStartupLocation),
		typeof(WindowItemsControl));

	public static readonly DependencyProperty RemoveDataItemWhenWindowClosedProperty = DependencyProperty.Register(
		"RemoveDataItemWhenWindowClosed",
		typeof(bool),
		typeof(WindowItemsControl),
		new FrameworkPropertyMetadata(true));

	static WindowItemsControl()
	{
		DefaultStyleKeyProperty.OverrideMetadata(typeof(WindowItemsControl), new FrameworkPropertyMetadata(typeof(WindowItemsControl)));
	}

	public bool ShowDialog
	{
		get { return (bool)this.GetValue(ShowDialogProperty); }
		set { this.SetValue(ShowDialogProperty, value); }
	}

	public Window Owner
	{
		get { return this.GetValue(OwnerProperty) as Window; }
		set { this.SetValue(OwnerProperty, value); }
	}

	public WindowStartupLocation WindowStartupLocation
	{
		get { return (WindowStartupLocation)this.GetValue(WindowStartupLocationProperty); }
		set { this.SetValue(WindowStartupLocationProperty, value); }
	}

	public bool RemoveDataItemWhenWindowClosed
	{
		get { return (bool)this.GetValue(RemoveDataItemWhenWindowClosedProperty); }
		set { this.SetValue(RemoveDataItemWhenWindowClosedProperty, value); }
	}

	protected override DependencyObject GetContainerForItemOverride()
	{
		return new WindowItemsControlItem(this);
	}

	protected override bool IsItemItsOwnContainerOverride(object item)
	{
		return item is WindowItemsControlItem;
	}

	protected override void PrepareContainerForItemOverride(DependencyObject element, object item)
	{
		(element as WindowItemsControlItem).Window.Content = item;
	}

	protected override bool ShouldApplyItemContainerStyle(DependencyObject container, object item)
	{
		// the item container style will be applied to the windows, not to the containers (which are surrogates for the window)
		return false;
	}

	private static void OnOwnerChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
	{
		var windowItemsControl = (WindowItemsControl)dependencyObject;
		var owner = (Window)e.NewValue;

		for (var i = 0; i < windowItemsControl.Items.Count; ++i)
		{
			var container = windowItemsControl.ItemContainerGenerator.ContainerFromIndex(i) as WindowItemsControlItem;

			if (container == null)
			{
				continue;
			}

			container.Window.Owner = owner;
		}
	}
}

Pretty straightforward stuff. Note the following:

it declares some properties (ShowDialog, Owner, WindowStartupLocation) that assist it in the display of child Windows
it declares a RemoveDataItemWhenWindowClosed property that can be used to prevent the control from removing data items when a window is closed. This can be useful in shutdown or other situations where windows are being closed programmatically rather than by the user
I don't apply the ItemContainerStyle to the containers themselves, but instead hold out so that I can apply them to the Windows they represent
I also make sure that any change of Owner is applied to any existing Windows
the default style is overridden to remove unnecessary stuff like the Border, because the WindowItemsControl will never actually be visible on screen

The WindowItemsControl works in conjunction with the WindowItemsControlItem, which looks like this:

public class WindowItemsControlItem : FrameworkElement
{
	private readonly WindowItemsControl windowItemsControl;
	private readonly Window window;

	static WindowItemsControlItem()
	{
		// there is no need for these items to be visible as they are simply surrogates for the windows that they display
		VisibilityProperty.OverrideMetadata(typeof(WindowItemsControlItem), new FrameworkPropertyMetadata(Visibility.Collapsed));
	}

	public WindowItemsControlItem(WindowItemsControl windowItemsControl)
	{
		windowItemsControl.AssertNotNull("windowItemsControl");

		this.windowItemsControl = windowItemsControl;
		this.window = this.CreateWindow(windowItemsControl);

		this.Loaded += delegate
		{
			if (this.windowItemsControl.ShowDialog)
			{
				this.window.ShowDialog();
			}
			else
			{
				this.window.Show();
			}
		};

		this.Unloaded += delegate
		{
			this.window.Close();
		};
	}

	public Window Window
	{
		get { return this.window; }
	}

	private Window CreateWindow(WindowItemsControl windowItemsControl)
	{
		var window = new Window
		{
			Owner = windowItemsControl.Owner,
			WindowStartupLocation = windowItemsControl.WindowStartupLocation
		};

		BindingOperations.SetBinding(window, Window.DataContextProperty, new Binding("Content") { Source = window });
		BindingOperations.SetBinding(window, Window.StyleProperty, new Binding("ItemContainerStyle") { Source = windowItemsControl });
		BindingOperations.SetBinding(window, Window.ContentTemplateProperty, new Binding("ItemTemplate") { Source = windowItemsControl });
		BindingOperations.SetBinding(window, Window.ContentTemplateSelectorProperty, new Binding("ItemTemplateSelector") { Source = windowItemsControl });

		window.Closed += delegate
		{
			// orphan the content because it might be hosted somewhere else later (including in another window)
			window.Content = null;

			// if the window closes, attempt to remove the original item from the underlying collection, which will result in this surrogate being removed too
			if (windowItemsControl.RemoveDataItemWhenWindowClosed)
			{
				var editableItems = windowItemsControl.Items as IEditableCollectionView;

				if (editableItems != null && editableItems.CanRemove)
				{
					editableItems.Remove(this.DataContext);
				}
			}
		};

		return window;
	}
}

This is all pretty self-explanatory, too. The important points to note are:

relevant properties on the WindowItemsControl are bound to the correct properties on the Windows themselves
Windows are displayed when the surrogate is initialized, and closed when the surrogate is unloaded
as mentioned earlier, Windows that are closed before the surrogate is destroyed (perhaps by the user clicking the close button) result in the related data item in the underlying collection being removed (unless the RemoveDataItemWhenWindowClosed property has been set to false). This, in turn, will cause the surrogate to be removed from the visual tree. In other words, if I close a widget Window, the corresponding WidgetViewModel will be removed from my collection of widget view models. Then, the ItemsControl will remove the related surrogate container from the visual tree.

Now, as I yearned for at the beginning of this post, I can simply change my ItemsControl to a WindowItemsControl, make minor adjustments to my ItemContainerStyle and it just magically works.

The Dude abides.

I created a little demo to show how it all works, which you can download below. Enjoy!

LogExportProvider

2011-11-12T12:51:00.001Z

We all know how important logging is to any non-trivial application, so it stands to reason that we should make it as pain free as possible to add logging to our application components. But at the same time, we don't want to sacrifice too much, such as having to deal with a sub-standard logging API, or with a logging infrastructure that doesn't log the obvious stuff on our behalf.

Wouldn't it be nice if logging were as simple as this:

namespace SomeNamespace
{
    public class SomeClass
    {
        [ImportingConstructor]
        public SomeClass(ILoggerService loggerService)
        {
            loggerService.Debug("Created an instance of {0}.", GetType().Name);
        }
    }
}

And, importantly, the resultant log entry looked something like this:

[2011-11-12 12:09:04,749] [1] [DEBUG] [SomeNamespace.SomeClass] Created an instance of SomeClass.

Prism ships with an ILoggerFacade interface that looks like this:

public interface ILoggerFacade 
{ 
    void Log(string message, Category category, Priority priority); 
}

This is obviously a very bare-bones interface. Every time you write a log statement you'll be forced to:

Format any parameters yourself.
Specify the category as a parameter (instead of having separate methods for each category)
Choose and specify a priority, even if it makes no sense for your code.
Incur the cost of any preparation for the log statement even if the pertinent log level is disabled because you have no way to check whether it is or not.

This is not very consumer-friendly at all, and you'll more than likely begin to find logging a more onerous task than it should be.

Another problem with using ILoggerFacade in Prism is the lack of any originating source in the output. There is nothing intrinsic to differentiate log statements from different components. If two components log the same message ("Initialized", for example), you will have no way to tell which component was initialized!

These problems forced me to come up with a custom solution. I wanted my logging to be based on log4net, and I wanted MEF to provide my components with a logging service instance. Moreover, that service must produce log entries that are specific to my component.

The first problem (poor API) was easiest to solve. I defined my own interface as follows:

public interface ILoggerService 
{ 
    bool IsVerboseEnabled 
    { 
        get; 
    }

    bool IsDebugEnabled 
    { 
        get; 
    }

    bool IsInfoEnabled 
    { 
        get; 
    }

    bool IsWarnEnabled 
    { 
        get; 
    }

    bool IsErrorEnabled 
    { 
        get; 
    }

    bool IsPerfEnabled 
    { 
        get; 
    }

    void Verbose(string message);

    void Verbose(string message, Exception exception);

    void Verbose(string message, params object[] args);

    void Debug(string message);

    void Debug(string message, Exception exception);

    void Debug(string message, params object[] args);

    void Info(string message);

    void Info(string message, Exception exception);

    void Info(string message, params object[] args);

    void Warn(string message);

    void Warn(string message, Exception exception);

    void Warn(string message, params object[] args);

    void Error(string message);

    void Error(string message, Exception exception);

    void Error(string message, params object[] args);

    IDisposable Perf(string message);

    IDisposable Perf(string message, params object[] args); 
}

As you can see, this interface provides many overloads for all the relevant combinations of parameters you might need. This saves you, the caller, from having to deal with the annoyance of formatting messages or exceptions. There are also properties that can be used to check whether a given log level is enabled, which can be crucial in performance-critical paths. Finally, notice the handy Perf overloads which can be used to measure the performance of a block of code like this:

using (loggerService.Perf("Authenticating the user")) 
{ 
    // do authentication here
}

The only thing I haven't included (because I haven't needed it) are generic Write methods that take the log level as a parameter instead of inferring the log level from the method name. Such methods can be useful in dynamic logging scenarios, so you may want to add your own.

With the API defined, it was time to write an implementation:

public sealed class Log4NetLoggerService : ILoggerService 
{ 
    private static readonly Level perfLevel = new Level(35000, "PERF"); 
    private readonly ILog log;

    public Log4NetLoggerService(ILog log) 
    { 
        log.AssertNotNull("log"); 
        this.log = log; 
    }

    public bool IsVerboseEnabled 
    { 
        get { return this.log.Logger.IsEnabledFor(Level.Verbose); } 
    }

    public bool IsDebugEnabled 
    { 
        get { return this.log.IsDebugEnabled; } 
    }

    public bool IsInfoEnabled 
    { 
        get { return this.log.IsInfoEnabled; } 
    }

    public bool IsWarnEnabled 
    { 
        get { return this.log.IsWarnEnabled; } 
    }

    public bool IsErrorEnabled 
    { 
        get { return this.log.IsErrorEnabled; } 
    }

    public bool IsPerfEnabled 
    { 
        get { return this.log.Logger.IsEnabledFor(perfLevel); } 
    }

    public void Verbose(string message) 
    { 
        this.log.Logger.Log(typeof(Log4NetLoggerService), Level.Verbose, message, null); 
    }

    public void Verbose(string message, Exception exception) 
    { 
        this.log.Logger.Log(typeof(Log4NetLoggerService), Level.Verbose, message, exception); 
    }

    public void Verbose(string message, params object[] args) 
    { 
        this.log.Logger.Log(typeof(Log4NetLoggerService), Level.Verbose, new SystemStringFormat(CultureInfo.InvariantCulture, message, args), null); 
    }

    public void Debug(string message) 
    { 
        this.log.Debug(message); 
    }

    public void Debug(string message, Exception exception) 
    { 
        this.log.Debug(message, exception); 
    }

    public void Debug(string message, params object[] args) 
    { 
        this.log.DebugFormat(CultureInfo.InvariantCulture, message, args); 
    }

    public void Info(string message) 
    { 
        this.log.Info(message); 
    }

    public void Info(string message, Exception exception) 
    { 
        this.log.Info(message, exception); 
    }

    public void Info(string message, params object[] args) 
    { 
        this.log.InfoFormat(CultureInfo.InvariantCulture, message, args); 
    }

    public void Warn(string message) 
    { 
        this.log.Warn(message); 
    }

    public void Warn(string message, Exception exception) 
    { 
        this.log.Warn(message, exception); 
    }

    public void Warn(string message, params object[] args) 
    { 
        this.log.WarnFormat(CultureInfo.InvariantCulture, message, args); 
    }

    public void Error(string message) 
    { 
        this.log.Error(message); 
    }

    public void Error(string message, Exception exception) 
    { 
        this.log.Error(message, exception); 
    }

    public void Error(string message, params object[] args) 
    { 
        this.log.ErrorFormat(CultureInfo.InvariantCulture, message, args); 
    }

    public IDisposable Perf(string message) 
    { 
        message.AssertNotNull("message"); 
        return new PerfBlock(this, message); 
    }

    public IDisposable Perf(string message, params object[] args) 
    { 
        message.AssertNotNull("message"); 
        args.AssertNotNull("args"); 
        return new PerfBlock(this, string.Format(CultureInfo.InvariantCulture, message, args)); 
    }

    private sealed class PerfBlock : IDisposable 
    { 
        private readonly Log4NetLoggerService owner; 
        private readonly string message; 
        private readonly Stopwatch stopwatch; 
        private bool disposed;

        public PerfBlock(Log4NetLoggerService owner, string message) 
        { 
            this.owner = owner; 
            this.message = message; 
            this.stopwatch = Stopwatch.StartNew(); 
        }

        public void Dispose() 
        { 
            if (!this.disposed) 
            { 
                this.disposed = true; 
                this.stopwatch.Stop(); 
                var messageWithTimingInfo = string.Format(CultureInfo.InvariantCulture, "{0} [{1}, {2}ms]", this.message, this.stopwatch.Elapsed, this.stopwatch.ElapsedMilliseconds); 
                this.owner.log.Logger.Log(typeof(Log4NetLoggerService), perfLevel, messageWithTimingInfo, null); 
            } 
        } 
    } 
}

It's all pretty straightforward - most of the code just delegates to log4net.

But notice how the constructor requires a log4net.ILog? Log4net provides various ways by which an ILog can be obtained, but we would like to use LogManager.GetLogger(Type ownerType), where ownerType is the type importing our service. How, then, can we expect MEF to provide instances of ILoggerService when our constructor has a dependency that it cannot satisfy?

MEF supports an abstraction called ExportProvider, which is an object that can dynamically provide exports to satisfy matching imports. The trick to making this all work seamlessly is a custom ExportProvider that creates instances of Log4NetLoggerService on the fly to satisfy imports of type ILoggerService. In order to create Log4NetLoggerService instances, the export provider must know the type of the object that is importing the service. Thankfully, MEF supports obtaining this information through its reflection services.

Here is the code for our custom ExportProvider:

public sealed class LoggerServiceExportProvider : ExportProvider 
{ 
    private static readonly ILoggerService log = new Log4NetLoggerService(LogManager.GetLogger(typeof(LoggerServiceExportProvider))); 
    private readonly IDictionary<Type, ILoggerService> loggerServiceCache;

    public LoggerServiceExportProvider() 
    { 
        this.loggerServiceCache = new Dictionary<Type, ILoggerService>(); 
    }

    protected override IEnumerable<Export> GetExportsCore(ImportDefinition definition, AtomicComposition atomicComposition) 
    { 
        var contractName = definition.ContractName;

        log.Verbose("Attempting to resolve contract name '{0}' to a log instance.", contractName);

        if (string.IsNullOrEmpty(contractName)) 
        { 
            log.Verbose("Contract name is null or empty - cannot resolve."); 
            yield break; 
        }

        if (!string.Equals(typeof(ILoggerService).FullName, contractName, StringComparison.Ordinal)) 
        { 
            log.Verbose("Incorrect contract - cannot resolve."); 
            yield break; 
        }

        if (definition.Cardinality != ImportCardinality.ExactlyOne) 
        { 
            log.Verbose("Cardinality is {0} - cannot resolve.", definition.Cardinality); 
            yield break; 
        }

        // in order to get a log4net logger, we need the type importing the logger facade 
        Type ownerType = null;

        if (ReflectionModelServices.IsImportingParameter(definition)) 
        { 
            log.Verbose("Parameter import detected.");

            var importingParameter = ReflectionModelServices.GetImportingParameter(definition); 
            ownerType = importingParameter.Value.Member.DeclaringType; 
        } 
        else 
        { 
            log.Verbose("Property import detected.");

            var setAccessor = ReflectionModelServices 
                .GetImportingMember(definition) 
                .GetAccessors() 
                .Where(x => x is MethodInfo) 
                .Select(x => x as MethodInfo) 
                .FirstOrDefault(x => (x.Attributes & MethodAttributes.SpecialName) == MethodAttributes.SpecialName && x.Name.StartsWith("set_", StringComparison.Ordinal));

            if (setAccessor == null) 
            { 
                log.Verbose("Set accessor for property not found - cannot resolve."); 
                yield break; 
            }

            ownerType = setAccessor.DeclaringType; 
        }

        if (ownerType == null) 
        { 
            log.Verbose("Owner type could not be determined - cannot resolve."); 
            yield break; 
        }

        log.Verbose("Owner type is '{0}'.", ownerType.FullName);

        ILoggerService loggerService;

        if (!this.loggerServiceCache.TryGetValue(ownerType, out loggerService)) 
        { 
            log.Verbose("Logger facade for owner type '{0}' is not yet cached - creating it.", ownerType.FullName);

            var logInstance = LogManager.GetLogger(ownerType); 
            loggerService = new Log4NetLoggerService(logInstance); 
            this.loggerServiceCache[ownerType] = loggerService; 
        }

        var export = new Export(contractName, () => loggerService); 
        yield return export; 
    } 
}

There are several things to note about this implementation:

Log service instances are cached. This means that if different instances of the same type import a logger service, they will (quickly) get the exact same instance.
Imports can be either via constructors or through properties. The export provider supports both.
The export provider itself includes logging statements, but it must do so with an explicitly created ILog instance. Obviously the export provider cannot import an ILoggerService itself or we'd have a chicken and egg problem!

We can tell MEF to use our custom ExportProvider in the usual fashion:

var compositionContainer = new CompositionContainer(new LoggerServiceExportProvider());

With this infrastructure in place, we achieve our objectives entirely. The code I included right at the beginning of this post will work, and any log entries will include the details of the originating type. And it is ridiculously easy for us to imbue components created by MEF with logging statements. Simply add the import and then invoke the simple-to-use APIs.

For a working example, click below. Enjoy!

Using InheritanceBehavior to Aid Theme Development

2011-08-29T10:54:00.001+01:00

If you've ever put together a custom theme for WPF, you'll know the value of comparing your theme to the system theme. You can quickly spot things that you've missed, or compare and contrast behavior. However, if your theme targets controls by type rather than by key (and most themes should), how do you ensure your theme isn't applied to a given control? That is, how do you ensure a given control inherits the system theme regardless of the application-defined themes?

Suppose you're implementing a style for buttons. It looks like this:

<Style TargetType="Button">
    <Setter Property="Background">
        <Setter.Value>
            <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
                <GradientStop Offset="0" Color="#5f9ea0"/>
                <GradientStop Offset="0.5" Color="#3f7e80"/>
                <GradientStop Offset="0.5" Color="#7fbec0"/>
                <GradientStop Offset="1" Color="#1f5e80"/>
            </LinearGradientBrush>
        </Setter.Value>
    </Setter>
    <Setter Property="Foreground" Value="White"/>
    <Setter Property="FontFamily" Value="Bauhaus 93"/>
    <Setter Property="FontSize" Value="12pt"/>
    <Setter Property="FontWeight" Value="Normal"/>
</Style>

You want to put together a little test control that shows your themed Button against a system-themed Button:

<StackPanel> 
    <Button>System Theme</Button> 
    <Button>Application Theme</Button> 
</StackPanel>

But that won't work - both buttons will inherit your theme. In this case, you can simply tell the second Button not to apply your Style, thus ensuring it inherits the system-defined one:

<Button Style="{x:Null}">System Theme</Button>

But what if you're theming something far more complex, like the DataGrid control? It has child controls (DataGridCell, DataGridRow, DataGridColumnHeader etc), each with their own style. How can you stop all those child controls from inheriting the styles provided by your theme? Well, sometimes the parent control (DataGrid in this case) will expose properties that allow you to override the styles for child controls:

<DataGrid Style="{x:Null}" CellStyle="{x:Null}" RowStyle="{x:Null}" .../>

But this is tedious, error-prone, and not all controls will expose such properties. What, then, is the diligent WPF journeyman to do?

The best way around this problem I've found is to make use of the little-known FrameworkElement.InheritanceBehavior property. This protected property specifies how resource and property inheritance lookups should behave from any FrameworkElement. We can define a simple control with an inheritance behavior to meet our needs as follows:

public sealed class UseSystemTheme : ContentControl 
{ 
    public UseSystemTheme() 
    { 
        this.InheritanceBehavior = System.Windows.InheritanceBehavior.SkipToThemeNow; 
    } 
}

Then, to prevent a control from inheriting our themed Style, we can simply wrap it in a UseSystemTheme. Going back to our Button example, it would look like:

<StackPanel> 
    <local:UseSystemTheme> 
        <Button>System Theme</Button> 
    </local:UseSystemTheme> 
    <Button>Application Theme</Button> 
</StackPanel>

Now it's easy to ensure we're comparing the application theme against the system theme. Moreover, you can use the same approach regardless of how complex the contained elements are. So it’ll work whether you’re styling a Button, a DataGrid, or whatever.

NOTE: I actually made my UseSystemTheme control a little more complex than presented here. I had it override its default Background value and set it to SystemColors.WindowBrush. Then I had to provide a template for it because, by default, a ContentControl does not honor its Background property. These changes ensure that every UseSystemTheme instance has the default brush as its background instead of inheriting whatever else you've set in your theme. It’s the child of the UseSystemTheme instance whose resource lookup is affected by InheritanceBehavior, not the UseSystemTheme instance itself!

Call of Duty 2 Startup Error

2011-07-01T21:07:00.001+01:00

Kind of random, even for my blog, but I got this error when attempting to re-live the pure awesome that is Call of Duty 2:

---------------------------
WIN_ERROR
---------------------------
Error during initialization:
Couldn't load default_localize.cfg. Make sure Call of Duty is run from the correct folder.

---------------------------
OK
---------------------------

I couldn’t find any decent advice on this, so I fiddled around a bit and noticed that the shortcut did not specify a working directory. I tried setting it to the directory to which I’d installed (D:\Program Files (x86)\Activision\Call of Duty 2\) and all was good. I’d imagine this happening in a couple of cases:

If you install to anywhere other than C:\
If you’re installing on a 64 bit machine

These are just theories though – I really can’t be bothered validating this, as I’m too busy shooting nazis.

RangeCollectionView

2011-04-09T14:04:00.001+01:00

WPF and Silverlight both support an abstraction called collection views, manifested by the ICollectionView interface. Whenever you bind to a collection, you're actually binding to a collection view, whether you do so explicitly or not. The original collection is exposed via the ICollectionView.SourceCollection property, but is often referred to as the "underlying collection".

WPF/SL both ship with some commonly-used collection view implementations, but sometimes you need something a little different. In a previous post I showed a custom collection view that can be used to implement virtual paging in Silverlight. In this post I'm going to show you a collection view that exposes a range of items in its underlying collection. This is useful, for example, when you have a larger data set that the user is able to "zoom into". An obvious example is the Google finance charts:

Notice how the chart requires the full set of data in order to render the lower preview area, as well as a subset of data in order to render the upper zoomed area. It is this subset that we want to be able to easily expose via a custom collection view.

My design for this collection view is quite straightforward. Here is the public API:

As you can see, I called the custom collection RangeCollectionView. It extends the built-in ListCollectionView and adds two important properties: StartIndex and EndIndex. These indexes demarcate the subset of the underlying collection that will be exposed by the range collection view. They are both inclusive.

Suppose you have a list of month names in order ("January"..."December"). If you wrap that list in a range collection view and set StartIndex to 5 and EndIndex to 9, that range collection view will expose only the following items:

June
July
August
September
October

Internally, RangeCollectionView uses the StartIndex and EndIndex properties to redefine the behaviour of various members defined by ListCollectionView. ListCollectionView is sufficiently flexible to allow this, which is a very good thing because it means we get certain features for "free", like sorting and grouping.

Going back to our chart example, consider that we can simply wrap our primary data set in a RangeCollectionView and then modify StartIndex and EndIndex according to the set of data the user has zoomed into. As the user zooms in, the start and end indexes move closer together. As the user zooms out, they widen.

The attached solution provides the code for RangeCollectionView, related unit tests, and a working example of how RangeCollectionView can be used to achieve an experience similar to that on Google finance. Here is an example of it in action:

Download Sample

TieredVisualStateManager

2011-03-23T19:17:00.001Z

A couple of posts ago, I discussed a custom visual state manager that allows you to impose a minimal amount of time for which a state must be active. In this post I'm going to push the visual state management infrastructure even further out of its comfort zone.

Imagine you've just finished developing a kick-ass WPF application that has extracted "ooooh"s and "aaaah"s from all the stakeholders. You're at the pub when your boss calls you and asks why the application keeps hanging on his machine. "Hanging?", you ask, reluctantly putting down the celebratory beer. "Yes, it stops and starts like a handsaw.", he replies. "Oh, you mean stuttering." "That's what I said - stuttering."

Intrigued, you head back into the office. Before your boss even fires up the application you notice the turbo button on his PC and your head drops into your hands. Predictably, your application takes a full minute to fire up and then renders at a frame rate of three Walt Disney animators.

"It's your machine.", you say dejectedly. "I don't care what it is - fix it. Today!"

You drag your feet all the way back to your desk, pondering the state of the job market in your area. You sit down at your desk and crack open your solution, the solution that was your pride and joy a mere hour ago. You don't bother firing up a profiler because you had already profiled and tweaked the performance of the application prior to shipping - you know there's nothing significant left to squeeze out of it.

At this point most of us would simply strip out animations, transitions, effects, and other non-critical niceties that are placing a strain on the frame rate. This has the advantage of getting your boss off your back (and you back at the pub), but the disadvantage of lowering the experience for users who have hardware dating post 1990. Not to mention the fact that you've likely had a UX designer put in significant amounts of thought and effort into producing the experience.

I anticipate this exact problem with the application I'm currently developing - there is a varied user base with varied hardware capabilities. OK, none have a turbo button that I'm aware of, but it wouldn't surprise me.

I decided to put some effort in to come up with a mechanism by which we could tier the experience in our application. That is, a mechanism by which the entire skin of the application can be scaled up or down based on some criteria. Whilst you could achieve this feat by maintaining multiple resource dictionaries - one for each tier in your scale - this results in a lot of duplication of work, since many tiers will include aspects present in other tiers. Another approach might involve some kind of global bindable property that determines the active tier, and then expecting XAML to trigger changes off that property. Again, this would work but would result in a mess of triggers in your templates and styles.

A far better approach, I think, is to create a custom visual state manager. Doing so can allow us to avoid duplication of work, and can keep our XAML relatively clean. This visual state manager, which I've called TieredVisualStateManager, must provide the following:

a global property tracking the tier that is currently active for the application
the ability to assign visual states and transitions to specific tiers
the ability to aggregate visual states and transitions together according to the tier to which they are assigned, and the active tier for the application

You can find a sample attached. In this sample, I've re-templated a CheckBox control as follows:

low tier: very simple graphic, no animations
medium tier: more appealing graphics, animates checking/unchecking by fading
high tier: same graphics as medium, same checking/unchecking transitions, but also adds another animation to shake the CheckBox up and down (when checking) or left and right (when unchecking). In addition, there is a non-stop glowing animation.

For the full control template, check out the attached sample. However, this outline gives you a taste for how things work:

<local:TieredVisualStateManager x:Key="TieredVisualStateManager"/>
    
<Style TargetType="CheckBox">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="CheckBox">
                <BulletDecorator VisualStateManager.CustomVisualStateManager="{StaticResource TieredVisualStateManager}">
                    <local:TieredVisualStateManager.TieredVisualStateGroups>
                        <local:TieredVisualStateGroupCollection>
                            <!--
                            CommonStates
                            -->
                            <local:TieredVisualStateGroup Name="CommonStates" Tier="Low">
                                <local:TieredVisualState Name="Normal"/>
                            </local:TieredVisualStateGroup>
                            <local:TieredVisualStateGroup Name="CommonStates" Tier="Medium">
                                <local:TieredVisualState Name="Normal">
                                    <!-- fancy brushes applied here -->
                                </local:TieredVisualState>
                            </local:TieredVisualStateGroup>
                                
                            <local:TieredVisualStateGroup Name="CommonStates" Tier="High">
                                <local:TieredVisualState Name="Normal">
                                    <!-- glowing animation applied here -->
                                </local:TieredVisualState>
                            </local:TieredVisualStateGroup>
                            <!--
                            CheckStates
                            -->
                            <local:TieredVisualStateGroup Name="CheckStates" Tier="Low">
                                <local:TieredVisualState Name="Unchecked"/>
                                <local:TieredVisualState Name="Checked">
                                    <!-- display check mark here -->
                                </local:TieredVisualState>
                            </local:TieredVisualStateGroup>
                            <local:TieredVisualStateGroup Name="CheckStates" Tier="Medium">
                                <local:TieredVisualStateGroup.Transitions>
                                    <VisualTransition From="Unchecked" To="Checked">
                                        <!-- fade check mark in here -->
                                    </VisualTransition>
                                    <VisualTransition From="Checked" To="Unchecked">
                                        <!-- fade check mark out here -->
                                    </VisualTransition>
                                </local:TieredVisualStateGroup.Transitions>
                            </local:TieredVisualStateGroup>
                                
                            <local:TieredVisualStateGroup Name="CheckStates" Tier="High">
                                <VisualStateGroup.Transitions>
                                    <VisualTransition From="Unchecked" To="Checked">
                                        <!-- shake the check box up and down here -->
                                    </VisualTransition>
                                    <VisualTransition From="Checked" To="Unchecked">
                                        <!-- shake the check box left and right here -->
                                    </VisualTransition>
                                </VisualStateGroup.Transitions>
                            </local:TieredVisualStateGroup>
                        </local:TieredVisualStateGroupCollection>
                    </local:TieredVisualStateManager.TieredVisualStateGroups>
                    
                    ...
                </BulletDecorator>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Importantly, notice how I have not repeated anything. For example, the transitions to fade the check mark in and out are defined in the medium tier, but they will also be present if the active tier is high. Similarly, the logic to turn on the check mark is defined in the low tier CheckStates, but is inherited by higher tiers. This aggregation is controlled by the TieredVisualStateManager.AggregateTiers property, which is true by default. Setting it to false may be useful in some scenarios, but it does mean you may need to repeat yourself.

When used carefully, the TieredVisualStateManager allows you to segregate your application experience so that users with rubbish hardware do not impose on the experience of users with decent hardware. Or it may be that some users have great machines, but just dislike animations, and would rather save that little bit of time by turning them off.

But the TieredVisualStateManager is not just about animations. You can control almost anything through this mechanism: turn effects on for high experiences, turn semi-transparency off for low experiences, remove parts of the visual tree for low experiences, etc. You can even change the tier structure to suit your needs - I just defined Low, Medium, and High because it makes sense for my scenario. Just make sure you define them in order from lowest to highest experience because the internal logic of TieredVisualStateManager depends on that order^†.

In order to actually set the active tier, you might use configuration, an options dialog, diagnostics of the user's machine, or some combination of both. I'm planning on just shipping with a high experience on, and exposing the setting somewhere in an options dialog.

"What about the Blend experience?", I hear you ask. Well, I personally don't use Blend the way in which it is purported to be used – I just don't think it works that well. I prefer using Blend for discrete tasks that are normally disconnected from my main solution. If I generate XAML with Blend, I always copy it manually and vet it for verbosity and other little pet hates of mine. Anyway, the fact is that we’ve taken the VSM sufficiently far enough out of its comfort zone that getting it to work in Blend is likely an impossibility. So I didn't put any effort into making the TieredVisualStateManager blendable. My plan is to obtain the high experience assets from the UX guy, and to "manually" apply tiering to them.

It’s an unfortunate story for Silverlight, too. For whatever reason, VisualStateGroup and VisualState are both sealed in Silverlight, which obviously breaks the entire approach to this problem. Perhaps it’s possible to hack around it, but until I need it in Silverlight I don’t plan on putting myself through that pain.

Download Sample

^†Yes, you could abstract the definition of tiers out into a property on TieredVisualStateManager, thus yielding even more flexibility.

BooleanToVisibilityConverter

2011-02-26T09:42:00.001Z

This is a small thing, really, but how often do you curse WPF's BooleanToVisibilityConverter (or Silverlight’s lack thereof) because it doesn't allow you to convert true to Visibility.Collapsed instead of Visibility.Visible? Or what about converting false to Visibility.Hidden instead of Visibility.Collapsed?

Well, it happens to me in just about every non-trivial project, so I tend to use my own BooleanToVisibilityConverter that addresses these requirements. Here it is:

public sealed class BooleanToVisibilityConverter : IValueConverter
{
    public bool IsReversed { get; set; }
    public bool UseHidden { get; set; }
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        var val = System.Convert.ToBoolean(value, CultureInfo.InvariantCulture);
        if (this.IsReversed)
        {
            val = !val;
        }
        if (val)
        {
            return Visibility.Visible;
        }
        return this.UseHidden ? Visibility.Hidden : Visibility.Collapsed;
    }
    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Now I can convert true to Visibility.Collapsed like this:

<local:BooleanToVisibilityConverter x:Key="whatever" IsReversed="true"/>
...
<Button Visibility="{Binding IsChecked, ElementName=someCheckBox, Converter={StaticResource whatever}}"/>

Or I can convert false to Visibility.Hidden rather than Visibility.Collapsed like this:

<local:BooleanToVisibilityConverter x:Key="whatever" UseHidden="true"/>
...
<Button Visibility="{Binding IsButtonEnabled, Converter={StaticResource whatever}}"/>

I can even convert true to Visibility.Hidden and false to Visibility.Visible like this:

<local:BooleanToVisibilityConverter x:Key="whatever" IsReversed="true" UseHidden="true"/>
...
<Button Visibility="{Binding IsButtonDisabled, Converter={StaticResource whatever}}"/>

Anyway, that's as much flexibility as I've needed when converting Boolean values to Visibility values.

MinimumTimeVisualStateManager

2011-02-19T12:41:00.001Z

A little while back I did some Silverlight work that was very focused on providing a fantastic user experience. As part of this work I developed a control that displayed a loading animation:

I then had views that would display this loading control whilst they're in a Loading state, and then hide it when they change to a Loaded state. That all worked fine. The problem was that sometimes - if the load operation completed quickly enough - the loading animation would briefly flash up on the screen and then disappear. Instead of improving the user experience, it was worsening it.

I could have applied a lengthy duration to the Loading -> Loaded transition, but that would apply indiscriminately to both fast loads, and slow loads. In other words, if the data happened to load slowly, users would have to wait for the slow load, and then again for the slower transition. Hardly compelling from a UX perspective.

What I really wanted to do was impose a minimum amount of time to spend in a particular state. That way I could say "the Loading state must be active for at least 1 second" rather than "the Loading state will be active for a minimum of 1 second". If the load operation took half a second, the loading animation would still display for a full second. If the load operation took two seconds, the loading animation would only display for that two second period (plus whatever transition time I specified).

Fortunately, the Visual State Manager infrastructure is extensible in that it allows custom a VisualStateManager instance to be associated with a given element. Such a custom manager might do something as simple as logging visual state changes, or something more complex. In my case, I wanted to enforce a minimum time for any state that desires one, which implies an attached property to set that minimum time and some logic to delay state changes when necessary.

Enter, the MinimumTimeVisualStateManager:

public class MinimumTimeVisualStateManager : VisualStateManager
{
    public static readonly DependencyProperty MinimumTimeProperty = DependencyProperty.RegisterAttached("MinimumTime",
        typeof(TimeSpan),
        typeof(MinimumTimeVisualStateManager),
        new PropertyMetadata(TimeSpan.Zero));

    private static readonly DependencyProperty StateChangeMinimumTimeProperty = DependencyProperty.RegisterAttached("StateChangeMinimumTime",
        typeof(DateTime),
        typeof(MinimumTimeVisualStateManager),
        new PropertyMetadata(DateTime.MinValue));

    public static TimeSpan GetMinimumTime(VisualState visualState)
    {
        if (visualState == null)
        {
            throw new ArgumentNullException("visualState");
        }

        return (TimeSpan)visualState.GetValue(MinimumTimeProperty);
    }

    public static void SetMinimumTime(VisualState visualState, TimeSpan minimumTime)
    {
        if (visualState == null)
        {
            throw new ArgumentNullException("visualState");
        }

        visualState.SetValue(MinimumTimeProperty, minimumTime);
    }

    private static DateTime GetStateChangeMinimumTime(DependencyObject dependencyObject)
    {
        Debug.Assert(dependencyObject != null);
        return (DateTime)dependencyObject.GetValue(StateChangeMinimumTimeProperty);
    }

    private static void SetStateChangeMinimumTime(DependencyObject dependencyObject, DateTime stateChangeMinimumTime)
    {
        Debug.Assert(dependencyObject != null);
        dependencyObject.SetValue(StateChangeMinimumTimeProperty, stateChangeMinimumTime);
    }

    protected override bool GoToStateCore(FrameworkElement control, FrameworkElement stateGroupsRoot, string stateName, VisualStateGroup group, VisualState state, bool useTransitions)
    {
        Debug.Assert(group != null && state != null && stateGroupsRoot != null, "Group, state, or stateGroupsRoot is null for state name '" + stateName + "'. Be sure you've declared the state in the XAML.");
        var minimumTimeToStateChange = GetStateChangeMinimumTime(stateGroupsRoot);

        if (DateTime.UtcNow < minimumTimeToStateChange)
        {
            // can't transition yet so reschedule for later
            var dispatcherTimer = new DispatcherTimer();
            dispatcherTimer.Interval = minimumTimeToStateChange - DateTime.UtcNow;
            dispatcherTimer.Tick += delegate
            {
                dispatcherTimer.Stop();
                this.DoStateChange(control, stateGroupsRoot, stateName, group, state, useTransitions);
            };
            dispatcherTimer.Start();

            return false;
        }

        return this.DoStateChange(control, stateGroupsRoot, stateName, group, state, useTransitions);
    }

    private bool DoStateChange(FrameworkElement control, FrameworkElement stateGroupsRoot, string stateName, VisualStateGroup group, VisualState state, bool useTransitions)
    {
        var succeeded = base.GoToStateCore(control, stateGroupsRoot, stateName, group, state, useTransitions);

        if (succeeded)
        {
            SetStateChangeMinimumTime(stateGroupsRoot, DateTime.MinValue);
            var minimumTimeInState = GetMinimumTime(state);

            if (minimumTimeInState > TimeSpan.Zero)
            {
                SetStateChangeMinimumTime(stateGroupsRoot, DateTime.UtcNow + minimumTimeInState);
            }
        }

        return succeeded;
    }
}

By way of explanation, the MinimumTimeVisualStateManager uses an attached property called MinimumTime which can be set on VisualState instances. When set, any calls to GoToStateCore will ensure that the required minimum time has been surpassed. If so, the state change succeeds as per normal. If not, a DispatcherTimer is used to switch states at an appropriate point later in time.

With this custom visual state manager, we can impose minimum times for states like this:

<Grid x:Name="root">
    <VisualStateManager.CustomVisualStateManager>
        <kb:MinimumTimeVisualStateManager/>
    </VisualStateManager.CustomVisualStateManager>
    
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup Name="LoadStates">
            <VisualState Name="Loading" kb:MinimumTimeVisualStateManager.MinimumTime="00:00:01">
            ...

In the above example, we ensure that the Loading state is active for at least 1 second.

By the way, this works equally well with Silverlight / WPF. You can download a sample WPF project showing this in action here.

Code Analysis without Visual Studio 2010

2011-01-31T21:04:00.003Z

This post provides step-by-step instructions on how to integrate Visual Studio 2010's code analysis into your build. If you've not yet done so, please read my first post for an overview of what will be achieved. If you'd prefer, you can integrate Visual Studio 2008's code analysis by following the instructions in my previous post. Whilst you will need a machine with Visual Studio 2010 installed, this won't be a requirement for building your project once it's set up correctly. I assume Visual Studio is installed in the default location - adjust paths as necessary.

Assume we are starting with the following directory structure:

Project
Lib
Src

Step 1: Copy Code Analysis Tooling

Copy the entire contents of C:\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop to Lib\Code Analysis.

Copy the entire contents of C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis to Lib\Code Analysis.

Copy the following files to Lib\Code Analysis:

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualC\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualC.Dll
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.CodeAnalysis.Sdk\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.CodeAnalysis.Sdk.dll
C:\Program Files\Microsoft Visual Studio 10.0\DIA SDK\bin\msdia100.dll
C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.CRT\msvcp100.dll
C:\Program Files\Microsoft Visual Studio 10.0\VC\redist\x86\Microsoft.VC100.CRT\msvcr100.dll

Step 2: Create Code Analysis Targets File

Create a file called CodeAnalysis.targets and put it in your Src directory. Here is a starting point for the contents of this file. You should tweak as necessary for your needs:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <!--
        Inject our own target before the code analysis runs.
        -->
        <RunCodeAnalysisDependsOn>
            ConfigureCodeAnalysis;
            $(RunCodeAnalysisDependsOn);
        </RunCodeAnalysisDependsOn>
        
        <!--
        Ensure code analysis is run
        -->
        <RunCodeAnalysis>True</RunCodeAnalysis>
        
        <!--
        Set this to false if you don't want all code analysis violations to be treated as errors.
        -->
        <CodeAnalysisTreatWarningsAsErrors>True</CodeAnalysisTreatWarningsAsErrors>
        <!--
        This should be set to resolve to the Lib directory, which must contain the code analysis tooling.
        -->
        <PathToLib>$(MSBuildProjectDirectory)\..\..\Lib\</PathToLib>
        <!--
        This should be set to resolve to the directory containing this targets file.
        -->
        <PathToTargets>$(MSBuildProjectDirectory)\..\</PathToTargets>
        
        <!--
        Setting these properties is required in order for the code analysis targets to execute correctly.
        Without setting these, it will look for the tooling under default installation directories instead
        -->
        <CodeAnalysisTargets>$(PathToLib)\Code Analysis\Microsoft.CodeAnalysis.Targets</CodeAnalysisTargets>
        <CodeAnalysisPath>$(PathToLib)\Code Analysis</CodeAnalysisPath>
        <!--
        Assign default code analysis rules
        -->
        <CodeAnalysisRuleSet>$(PathToTargets)CodeAnalysis.Default.ruleset</CodeAnalysisRuleSet>
    </PropertyGroup>
    <UsingTask AssemblyFile="$(PathToLib)\MSBuildSdcTasks\Microsoft.Sdc.Tasks.dll" TaskName="StringComparison"/>
    <Target Name="ConfigureCodeAnalysis">
        <!--
        Assume that any projects with ".Tests" in their names are test projects
        -->
        <StringComparison Comparison="Contains" Param1="$(AssemblyName)" Param2=".Tests">
            <Output TaskParameter="Result" PropertyName="IsTestProject"/>
        </StringComparison>
        <!--
        Assign different rules for test projects (more relaxed)
        -->
        <CreateProperty Condition="$(IsTestProject)" Value="$(PathToTargets)CodeAnalysis.Tests.ruleset">
            <Output TaskParameter="Value" PropertyName="CodeAnalysisRuleSet"/>
        </CreateProperty>
    </Target>
</Project>

Step 3: Create Rule Sets

Create files called CodeAnalysis.Default.ruleset and CodeAnalysis.Tests.ruleset in your Src directory. You can create these files with Visual Studio 2010 by choosing File / New / File / Code Analysis Rule Set. Alternatively, you can just copy the files from the example in the download.

Step 4: Enable Code Analysis for Relevant Projects

For every project that requires code analysis, open the .csproj file and insert the following before the import of Microsoft.CSharp.targets:

<Import Project="..\CodeAnalysis.targets" />

NOTE: it's very important that this be inserted before the import of Microsoft.CSharp.targets, not after.

Step 5: Tweak as Necessary

You may wish to tweak the CodeAnalysis.targets, CodeAnalysis.Default.ruleset, and CodeAnalysis.Tests.ruleset files in order to alter the rules that are enabled, the conditions in which sets of rules are used, etc. As mentioned above, you can use VS2010 to create and edit .ruleset files.

Code analysis is now integrated with your projects. Where you're building from is irrelevant - whether it's Visual Studio, the command line, or your build server. In all cases code analysis will execute for your project. You can download an example solution showing all this in action here.

Troubleshooting

If you get CA0001 Phx.FatalError, you likely need to register the msdia100.dll on the build machine:

regsvr32 msdia100.dll

You could possibly incorporate this into your build script, too, if your build user has sufficient rights.

Download Example

Code Analysis without Visual Studio 2008

2011-01-31T21:04:00.001Z

This post provides step-by-step instructions on how to integrate Visual Studio 2008's code analysis into your build. If you've not yet done so, please read my first post for an overview of what will be achieved. If you'd prefer, you can integrate Visual Studio 2010's code analysis by following the instructions in my next post. Whilst you will need a machine with Visual Studio 2008 installed, this won't be a requirement for building your project once it's set up correctly. I assume Visual Studio Team Edition is installed in the standard location - adjust paths as necessary.

Assume we are starting with the following directory structure:

Project
Lib
Src

Step 1: Copy Code Analysis Tooling

Copy the entire contents of C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop to Lib\Code Analysis.

Copy the entire contents of C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\CodeAnalysis to Lib\Code Analysis.

Step 2: Create Code Analysis Targets File

Create a file called CodeAnalysis.targets and put it in your Src directory. Here is a starting point for the contents of this file. You should tweak as necessary for your needs:

<?xml version="1.0" encoding="utf-8"?>

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <!--
        Inject our own target before the build.
        -->
        <BuildDependsOn>
            ConfigureCodeAnalysis;
            $(BuildDependsOn);
        </BuildDependsOn>

        <RunCodeAnalysis>True</RunCodeAnalysis>
        
        <!--
        Set this to false if you don't want all code analysis violations to be treated as errors.
        -->
        <CodeAnalysisTreatWarningsAsErrors>True</CodeAnalysisTreatWarningsAsErrors>

        <!--
        These are the default code analysis rules that will be applied to any project importing this targets file.
        Note that the lack of $(CodeAnalysisRules) in the definition of CodeAnalysisRules means that individual
        projects cannot override these settings. This is intentional.
        -->
        <DefaultCodeAnalysisRules>+!Microsoft.Design#CA1012;-!Microsoft.Design#CA2210</DefaultCodeAnalysisRules>

        <!--
        These are the code analysis rules that will be applied to any tests project importing this targets file.
        Test projects are identified by having ".Tests" in their name.
        -->
        <TestsCodeAnalysisRules>+!Microsoft.Design#CA1012;-!Microsoft.Design#CA2210</TestsCodeAnalysisRules>

        <!--
        This should be set to resolve to the Lib directory, which must contain the code analysis tooling.
        -->
        <PathToLib>$(MSBuildProjectDirectory)\..\..\Lib</PathToLib>

        <!--
        Setting these properties is required in order for the code analysis targets to execute correctly.
        Without setting these, it will look for the tooling under default installation directories instead, which probably
        won't (and shouldn't) be present on the build server.
        -->
        <CodeAnalysisPath>$(PathToLib)\Code Analysis</CodeAnalysisPath>

        <CodeAnalysisRules>$(DefaultCodeAnalysisRules)</CodeAnalysisRules>
    </PropertyGroup>

    <UsingTask AssemblyFile="$(PathToLib)\MSBuildSdcTasks\Microsoft.Sdc.Tasks.dll" TaskName="StringComparison"/>

    <Target Name="ConfigureCodeAnalysis">
        <!--
        Assume that any projects with ".Tests" in their names are test projects
        -->
        <StringComparison Comparison="Contains" Param1="$(AssemblyName)" Param2=".Tests">
            <Output TaskParameter="Result" PropertyName="IsTestProject"/>
        </StringComparison>

        <!--
        Assign different rules for test projects (more relaxed)
        -->
        <CreateProperty Condition="$(IsTestProject)" Value="$(TestsCodeAnalysisRules)">
            <Output TaskParameter="Value" PropertyName="CodeAnalysisRules"/>
        </CreateProperty>
    </Target>
    
    <Import Project="..\Lib\Code Analysis\Microsoft.CodeAnalysis.targets" />
</Project>

NOTE: For the sake of brevity, I have only included a couple of rule definitions in the above snippet. Please download the example solution to obtain a more comprehensive list.

Step 3: Enable Code Analysis for Relevant Projects

For every project that requires code analysis, open the .csproj file and insert the following after the import of Microsoft.CSharp.targets:

<Import Project="..\CodeAnalysis.targets" />

NOTE: it's very important that this be inserted after the import of Microsoft.CSharp.targets, not before.

Step 4: Tweak as Necessary

You may wish to tweak the CodeAnalysis.targets file in order to alter the rules that are enabled, the conditions in which sets of rules are used, etc. The file is pretty self-explanatory but includes comments as well.

Download Example

Code Analysis without Visual Studio

2011-01-31T20:52:00.001Z

The code analysis tool included in Visual Studio is like a code review, only it's super-fast and doesn't require the twisting of any arms. It checks your .NET binaries for common mistakes in various areas such as design, performance, and security. You can instruct it to treat specific issues as errors so that your project fails to build until problems are rectified. You can even write custom rules and plug them in, or just download some rules provided by the community.

Because it's fast and automated, it is feasible to have code analysis run *every time you build*. This is ideal because identifying these problems early can save you a bunch of time in the long run. Relying on developers running the tooling "when they get a chance" is bound to result in non-conformance to the rules. Violations will compound as time goes by and developers will end up not bothering to run the tooling because of the sheer number of violations present.

Visual Studio makes it easy to configure code analysis to run for individual projects on every build, but only when building within Visual Studio itself. What happens when you build outside of Visual Studio? What happens when you want the same set of rules configured for your projects to execute during command line builds, or on your continuous integration server?

The answer is that you need to do a little more work to get this going. There seems to be a fair amount of misinformation out there on this subject. And Microsoft don't seem to be advertising the fact that it's possible, instead preferring to recommend installing VS on your build server. Not only is that expensive financially, it's expensive in terms of time taken to set up and maintain your build servers.

In the following two posts I will provide step-by-step instructions for enabling code analysis within your 2008/2010 solution with the following properties:

The tooling is shared and self-contained. No need for developers to install anything, nor for you to install anything on your build servers.
The tooling is executed whether building in Visual Studio, the command line, or on your build server.
All the heavy lifting is encapsulated in a separate targets file, which can simply be imported by projects for which code analysis will be executed.
The rules executed can be customized based on the assembly under test. For example, you might relax rules for unit test projects.

The next post will describe how to enable code analysis integration for Visual Studio 2008, and the one following that will cover the same topic for Visual Studio 2010. The steps are slightly different because code analysis underwent some changes in 2010.

By the way, if you're wondering "why not just download FxCop and integrate that?" then the answer is that FxCop has fewer rules and has a slower engine than code analysis (in 2010 at least). In general, you can consider FxCop the outdated predecessor to code analysis.

MEF Filtered Catalog

2010-10-23T15:36:00.001+01:00

Another piece of MEF code Glenn prompted me to share is a filtered catalog. Here it is in its entirety:

private abstract class FilteredCatalog : ComposablePartCatalog
{
    private readonly ComposablePartCatalog catalogToFilter;

    public FilteredCatalog(ComposablePartCatalog catalogToFilter)
    {
        this.catalogToFilter = catalogToFilter;
    }

    public override IQueryable<ComposablePartDefinition> Parts
    {
        get
        {
            return from part in this.catalogToFilter.Parts
                   from exportDefinition in part.ExportDefinitions
                   where this.IsMatch(part) && this.IsMatch(exportDefinition)
                   select part;
        }
    }

    public override IEnumerable<Tuple<ComposablePartDefinition, ExportDefinition>> GetExports(ImportDefinition definition)
    {
        return from export in base.GetExports(definition)
               where this.IsMatch(export.Item1) && this.IsMatch(export.Item2)
               select export;
    }

    protected virtual bool IsMatch(ComposablePartDefinition composablePartDefinition)
    {
        return true;
    }

    protected virtual bool IsMatch(ExportDefinition exportDefinition)
    {
        return true;
    }
}

The idea of this abstract class is to make it easy for you to provide filtering logic to pick and choose the parts that are of interest to you. For example, suppose you want a catalog to filter out all services:

private sealed class NonServiceCatalog : FilteredCatalog
{
    public NonServiceCatalog(ComposablePartCatalog catalogToFilter)
        : base(catalogToFilter)
    {
    }

    protected override bool IsMatch(ExportDefinition exportDefinition)
    {
        // in this case, services are identified via some metadata
        return !exportDefinition.Metadata.ContainsKey("Mode");
    }
}

It is entirely possible that you could alter FilteredCatalog such that it is concrete and takes lambdas to filter out parts. However, I prefer the explicit approach because it results in clear code such as:

rootCatalog.Catalogs.Add(new NonServiceCatalog(catalog));

Well, that’s it really. A simple, but effective way of filtering your MEF parts.

Enjoy!

Failing Early with MEF

2010-09-20T20:21:00.001+01:00

Several weeks back I had the pleasure of having Glenn Block over for dinner and discourse. I showed him a project I've been working on, and naturally our conversation centred around my use of MEF and REST. Glenn asked that I do a couple of posts on some of the MEF stuff I had done, so this is the first one.

One of the things I frequently found happening when using MEF was:

Make a few simple changes
Run the application
Get a runtime exception
Trawl through the hierarchy of exceptions, only to find that it was a simple composition problem

More often than not, I had just forgotten to add the appropriate metadata to my types. Since this is something that can be caught early, I felt compelled to do exactly that. However, I also wanted to ensure that this verification did not result in a bloated release deployment. I just wanted something to aid the developer whilst building the application.

I came up with this:

private static void VerifyComposition()
{
#if DEBUG
    var compositionInfo = new CompositionInfo(rootCatalog, container);
    
    using (var stringWriter = new StringWriter(CultureInfo.InvariantCulture))
    {
        CompositionInfoTextFormatter.Write(compositionInfo, stringWriter);
        var compositionDetail = stringWriter.ToString();
        var errorDetected = compositionDetail.Contains("[Primary Rejection]");
        
        if (errorDetected)
        {
            Debugger.Break();
            Debug.Assert(false, "Composition error detected:" + Environment.NewLine + Environment.NewLine + compositionDetail);
        }
    }
#endif
}

This uses the CompositionInfo type, which is included in the Microsoft.ComponentModel.Composition.Diagnostics assembly. As an aside, I had to build my own version of this assembly for use with Silverlight since there is none provided out of the box.

The CompositionInfo class is used to dump detailed diagnostics of composition into a string. The string is then examined for any issues by searching for "[Primary Rejection]". If any error is detected, I break into the debugger so the developer can examine the composition dump. This means the workflow above is replaced with this one (same number of steps, but far less time-consuming):

Make a few simple changes
Run the application
Debugger breaks letting me know there is a composition problem
Examine compositionDetails in the debugger to get the details of the composition error

As Glenn pointed out, it may be that you want to tweak the string search according to your particular project. In my case, I want any composition problem at all to be detected ASAP and to bail out.

Notice also that this whole affair is wrapped in a #if DEBUG block. Not only does this prevent this code itself from appearing in a release build, it also prevents the Microsoft.ComponentModel.Composition.Diagnostics assembly from appearing in your release output (assuming you don't use it elsewhere). This was particularly important for me because it's a Silverlight app, and I wanted the download size to be as small as possible.

I hope this is of some use.

Virtual Paging in Silverlight

2010-07-29T18:30:00.001+01:00

Silverlight 3 added the IPagedCollectionView interface (and concrete implementation PagedCollectionView) to support paging through a large result set. The DataPager control can work with an implementation of IPagedCollectionView to allow users to page through the large data set by clicking on a page number. It typically looks like this:

Unfortunately (you knew it was coming), these new types don't offer support for virtual paging. Virtual paging is where you're paging data behind the scenes, but the user isn't explicitly changing pages as they do with the DataPager control. To them, the data just appears in a big ol' list. As they scroll around the list, data is paged in as necessary. If they move slowly down the list, they would quite possibly never know that data is being paged.

In the WPF world, it is possible to achieve virtual paging by implementing a collection view that simply retrieves data lazily if and when it is requested. This works because WPF's binding infrastructure will only request items in your source collection if it needs them. Alas, this is not the case in Silverlight. Silverlight will aggressively iterate over all items in your underlying collection regardless of whether they're visible. Thus, if you attempt the WPF trick of lazily loading data on request, you'll end up paging in all the data as soon as the binding kicks in. How annoying.

I tried a few things to make sure that Silverlight really was that dumb. For example, I tried providing an IList<T> implementation to see whether it would use the Count property to avoid the iteration over all the data, figuring perhaps it just needed to know how many items were in the data source in order to calculate the scrollable extent. No dice. I tried a few other things, but all attempts at thwarting Silverlight's aggressive iteration over the data source came up empty-handed.

But the thing is, I feel really strongly about the usability benefits of virtual paging versus manual paging. The former is far more intuitive and simple to use. I was simply not prepared to forgo this feature in my app, so I pressed on.

I came up with something of a compromise that goes like this: fine then, Miss Silverlight, if you insist then you may iterate over my entire source, but I'll just be giving you handles to the data. Those handles won't result in data being loaded - that will only happen when the handle's value is de-referenced. The value will only be de-referenced by bound UI components. And by virtue of UI virtualization, that will only happen when the user scrolls to within the region of that data.

So what do the handles look like? Initially I experimented with using Lazy<T> since it's built-in and seemed apropos. It actually worked fine when used synchronously. But loading the data on the UI thread would be really bad, effectively causing the UI to hang when the user scrolls through the data. When I attempted to extend Lazy<T> and add asynchronous support, things got ugly. Therefore, I scrapped it altogether and instead wrote my own AsyncLazy<T> class. On the surface, it looks a lot like Lazy<T>:

But is has some key differences in both behavior and API. Firstly, accessing Value when the value is yet to be loaded will instantly return null. But it will also start resolving the value on a background thread, after which the Value property is updated with the result. The IsValueCreated property will not return true until the background thread has done its thing and Value is set. Crucially, AsyncLazy<T> implements INotifyPropertyChanged so that any UI elements bound to Value or IsValueCreated will refresh accordingly as values load.

I then have a collection view called LazyAsyncCollectionView<T>. This is an abstraction over the large underlying data set that will be consumed by your view components. You tell it the total number of items in the collection, the size of each page, and give it a lambda with which it can load a specific page. It then takes care of ensuring that pages are loaded as and when they are required. Importantly, it's actually an IEnumerable<AsyncLazy<T>> rather than IEnumerable<T>. This means that Silverlight can iterate over the entire view without us needing to load all the data. The data will only be loaded if the Value property is de-referenced, which is instigated by bindings in the view.

The view needs to be aware of the fact that it's bound to an AsyncLazy<T> rather than a T. Ergo, bindings look like this:

<TextBlock Text="{Binding Value.Property}"/>

where Value is the aforementioned property on AsyncLazy<T>. If you have a lot of properties and you don't like dereferencing Value all the time, you could bind a container's DataContext like this:

<StackPanel DataContext="{Binding Value}">
    <TextBlock Text="{Binding SomeProperty}"/>
    <TextBlock Text="{Binding SomeOtherProperty}"/>
</StackPanel>

The demo I put together uses all this stuff to display a list of people, the specifics of which you control (being a demo). As pages are being loaded, it displays a simple animation as a placeholder for the data. See the screenshot to the right to see what I mean.

I mentioned that this whole thing was a compromise. Here are the primary weaknesses of the approach:

the need for an intermediary type is regrettable, but – as explained above – necessary given the current limitations of Silverlight’s binding infrastructure.
it is not a true virtualization solution in the sense that it will not unload data. So if the user views the entire result set, all data will be loaded into memory. It is likely possible to alter the code so that it keeps a maximum number of pages in memory and intelligently unloads data where possible. I may well do that when I integrate this into my project.
there is still the possibility that a very large number of AsyncLazy<T> instances will be created, thereby draining memory and CPU cycles. If there is potential for your underlying list to surpass a certain threshold (say, 100,000 entries), it would be prudent to set an upper bound on how many records you will display. After all, is it really that useful to allow users access to all that data? Personally, I will be setting an upper limit of 10,000 and including a message to the effect of "please refine your search" if the server reports more than that number of entries in the data set.
as discussed above, the UI needs to bind indirectly to the underlying data via the Value property on AsyncLazy<T>. Whilst not ideal, this is a price I am willing to pay in order to get this feature. It's possible you could implement AsyncLazy<T> as a DynamicObject that forwards property accesses onto the underlying data item. However, this could result in significant overhead and I haven't experimented with it yet.

It's also incomplete. I'm literally blogging about this before I use it in anger, mostly because I'm just so excited I actually got it to work. However, my scenario may be simpler than yours. Here are some things that are missing/incomplete:

error handling. What happens if the page fails to load? Currently, it just catches the exception and continuously retries until it succeeds. I will definitely be enhancing this, possibly to report errors via the AsyncLazy<T> class. That way, the UI could respond accordingly, perhaps by displaying a failure message and retry link.
selection handling. It so happens that I do not need to support selection. I'm just displaying a large list of non-editable data (search results, if you're wondering). If you need selection support (e.g. if you use this with a ListBox), then you'll want to implement the pertinent members of ICollectionView, such as CurrentItem and CurrentPosition. I shouldn't imagine it would be too difficult.
grouping/sorting/filtering. If these were implemented, they would need to delegate back to the consumer of LazyAsyncCollectionView<T>. It doesn't make sense for these operations to occur on the client because all data would need to be loaded before it could be grouped, sorted, or filtered. However, if the server-side function supported these mechanisms, then it would make sense to delegate. I think I'll be adding sorting support for my own purposes, since my server-side function does support it. I need to think more about how I'm going to achieve this cleanly.
the AsyncLazy<T> class assumes null is not a valid value for a data item. This is fine for my purposes, but may not be for you. If necessary, you could add a bool to track whether the value has been loaded rather than checking for null. Given the sheer number of AsyncLazy<T> instances that could be created, I was being careful to minimize the memory footprint of each instance. 1 bool is insignificant, but 1 million?

Enjoy!

Download Project

Popup.StaysOpen in Silverlight

2010-07-14T16:44:00.001+01:00

Continuing on with the theme of restoring some WPF goodness to Silverlight, here is an attached behavior that gives Silverlight’s Popup control a handy StaysOpen property. It builds on top of the placement behavior I presented in my last post, so I’ve just supplemented the demo I did for that post. Call me lazy.

Usage looks like this:

<Popup b:Popup.StaysOpen="False">
    <TextBlock>Popup contents</TextBlock>
</Popup>

The only limitations I know of are:

The Popup in question must be closed when you set the StaysOpen property. If, for example, your Popup is already open when your application first starts, events won’t hook up correctly.
The Popup’s parent is used to determine whether the user has clicked outside the bounds of the Popup, and therefore whether the Popup should be closed. So you should host the Popup as far up in your visual tree as appropriate, or you could add another dependency property with which you can explicitly specify the parent. I haven’t needed the latter idea yet, so haven’t bothered to add it – maybe I’ll need it later.

Enjoy!

Download Project

Silverlight Popup with Target Placement

2010-07-08T15:53:00.001+01:00

Silverlight, eh? It takes everything you knew and turns it into a confusing mish-mash of falsities, half-truths, and – just occasionally - truths.

One such falsity would be in the placement of Popup controls relative to another control. You can just set a PlacementTarget like in WPF, right? Nope. All you've got to work with are the HorizontalOffset and VerticalOffset properties, which specify an offset relative to the Popup's parent. Not much help on their own, really.

To imbue Silverlight with the WPF goodness that is relative Popup placement, I've written an attached behavior that positions a Popup according to:

a placement target
any number of preferred orientations, which state how you’d like the Popup to be positioned with respect to the placement target

Usage looks like this:

<Popup b:PopupPlacement.PlacementTarget="{Binding ElementName=someElement}">
    <b:Popup.PreferredOrientations>
        <b:PopupOrientationCollection>
            <b:PopupOrientation Placement="Top" HorizontalAlignment="Center"/>
            <b:PopupOrientation Placement="Bottom" HorizontalAlignment="Center"/>
            <b:PopupOrientation Placement="Right" VerticalAlignment="Center"/>
            <b:PopupOrientation Placement="Right" VerticalAlignment="TopCenter"/>
        </b:PopupOrientationCollection>
    </b:Popup.PreferredOrientations>

    <TextBlock>My popup's contents</TextBlock>
</Popup>

The above will attempt to position the Popup centred above someElement. Failing that, it will attempt to place it centered below someElement. Failing that, it will attempt to place it with its top centred to the right of someElement. Failing that, it will cycle through all other possible permutations of orientations and choose the first one that fits. Failing that, it will resort to just displaying the Popup with your most desired orientation, even though the Popup doesn’t fit.

Notice how the horizontal alignment is only relevant if the Popup is positioned above or below the placement target, and the vertical alignment is only relevant if the Popup is positioned to the left or right of the placement target. Nothing stops you from specifying an irrelevant alignment, but it will be ignored.

The actual orientation chosen is exposed via the ActualOrientation property. You might use this (as I have in my own project – though not in the attached demo) to alter the appearance of the Popup’s contents.

The attached download includes all the code (it's only 300 lines or so) and a demo (see screenshot). The demo specifies only one preferred orientation, but it puts you in control of what the values are for the orientation. You can resize the space available to the Popup by using the grid splitters. The actual orientation chosen for is shown at the bottom. Thus, you can play with different orientations and see how the behavior differs when it has insufficient space in which to fit the Popup.

Enjoy!

Download Project

Adjusting the Aggressiveness of your PS3 Fan

2010-05-24T13:23:00.001+01:00

Most people know that the PS3 has different speeds at which its fan can spin, resulting in varying levels of noise, from "is that thing even on?" to "omg, the house is taking off!" A lesser known fact is that you can adjust how aggressive the PS3 is with its fan. That is, what temperatures trigger different fan speeds.

If you're like me then, well, I'm sorry to hear that - but if you are, you use your PS3 more as a media device than as a gaming one. Consequently, you'd much prefer a quieter PS3 so that you can actually hear Rose whisper “I love you” to Jack (well over an hour after “the only part you want to watch again”, but you’re still watching, aren’t you? Aren’t you!?). To that end, you may need to ensure your PS3 has a less aggressive cooling policy.

Or maybe you freak out at the very thought of your PS3's electronic innards being ruthlessly tortured by scorching temperatures, while the fan watches on cruelly, doling out only just enough relief to keep its victim alive. Whether you’re into rubbish movies or personifying inanimate objects, this guide may well be for you.

First, some caveats:

Your warranty will be voided.
I won't be held responsible for any damage you do to your PS3, either in the process of making the adjustment, or as a consequence of any adjustments made.

Secondly, here's what you'll need to make the adjustments:

A star screwdriver or attachment (size T10, whatever that means).
A phillips head screwdriver or attachment (#2).
Long fingernails, a flat-head screwdriver, or some other implement to pry the hard drive cover free.
Patience. It can take a number of iterations to get it just right.

Now then, to the guide . . .

Step 1: Remove the top cover

Remove the warranty sticker from the side of the unit, and then pry out the little rubber plug. After doing so, you'll you'll see the head of a star screw. Use your star screwdriver or attachment to unscrew and remove it. Then slide the top cover out and lift it off.

Step 2: Remove the inner casing

Using your phillips head screwdriver or attachment, remove all 7 screws holding the inner casing. One is shorter than the rest, and is marked by an “S” on the casing. With all screws removed, press in the tab at the back of the unit and then lift it off.

Step 3: Remove the loose component

This step may not be entirely necessary, but I found it much easier to remove the bottom casing if the component on the left of the unit (when looking at it from the rear) is first removed because it is loose and prone to moving about, especially in the next step.

To remove it, lift it and unplug the wire from its right hand side. Then carefully lift up the plastic latch holding the flat cord down. It is now detached and can be moved to one side.

Note: If you apply too much pressure to the latch it can come apart, so be careful. If it does, don't panic unless you damaged it (at which point, feel free to panic). If it's still undamaged, you can reattach it quite easily once you know how it fits together. Study the form of both parts carefully and you'll see it only goes together one way - the detached part kind of slides into and under the fixed part.

Step 4: Remove the bottom casing

Using your phillips head screwdriver or attachment, remove all 7 screws holding the bottom casing. Then remove the hard drive cover using a flat head screwdriver or other appropriate implement. Now, flip the entire unit over, being very careful to hold its innards as you do so - they will fall out if you don't. The bottom casing then lifts straight off.

Step 5: Adjust the fan

Near the rear of the fan and off to the side is a little plastic casing with a tiny screw on top. It's not a normal screw in the sense that it never stops turning. You can turn it in either direction all day long without it tightening or coming loose. Tightening it (turning it clockwise) will increase the aggressiveness of the fan, whereas loosening it (turning it anti-clockwise) will decrease the aggressiveness of the fan.

If you keep tightening it you will eventually hear a faint clicking sound on every revolution. That means it's as aggressive as it will go. If you leave it in this position, your PS3 will always run its fan at full speed. Useful if you lack a hair-dryer in your household.

If you loosen it too much, your PS3 won't turn its fan on at all and will overheat within minutes. Note that the PS3 firmware has a fail-safe such that your machine will display an error message and automatically shut itself down if it becomes too hot (and it will, trust me).

What you need to find is that happy middle-ground where the fan isn't so aggressive that it is impractical as a media extender, but where it is aggressive enough to keep your unit sufficiently cooled whilst playing Call of Duty Modern Warfare 18.

For me, it was 5¾ rotations back from the most aggressive setting. Your mileage may vary. Small adjustments really are significant - that final quarter of a turn tweak is what perfected it for me.

What's frustrating is that there's no easy way to test your adjustments. You have to put everything back together again and give it a whirl. I did this literally ten times before I got it just right. I skipped as many screws as I felt comfortable skipping, but always ensured that all cases were in place. I did this partly for safety reasons, but also because I didn't want extra airflow biasing my tests.

Putting everything back together is just the reverse procedure to the above steps.

Enjoy!

Automatic Configuration Exposure with MEF

2010-02-08T15:21:00.000Z

Glenn Block’s recent post on exposing configuration information through MEF intrigued me. What I found myself wondering was whether there was a way to make the exports automatic. That is, having a newly-added configuration setting in your settings file automatically made available to importers, without any extraneous code to do so.

A Failed Solution

My initial attempt to solve this problem involved the use of a CustomTypeDescriptor with dynamic properties for each configuration value present in the App.config file. After Glenn helpfully – and gracefully - pointed out typos in my ~~aspiring constants~~ magic strings, I still wasn’t able to get this approach to work.

It appears as though MEF does not use TypeDescriptor.GetProperties to get the properties of a part, so my approach was doomed to failure from the get-go.

A Successful Solution

Never mind though, because Glenn also pointed me towards MEF’s ExportProvider abstraction. An export provider can surface exported values to MEF. Thus, we can take values from configuration and ensure they are available to parts that want to import those values.

The export provider abstraction made things much simpler, but there were some complications:

I wanted to allow parts to import specific values from the <appSettings/> section, or import an entire custom configuration section.
I wanted parts to be able to declare imports with their intended types, and have strings in the <appSettings/> section automatically converted to that type.

The first complication was trivial to work around by comparing the imported contract name against both the app settings and custom configuration sections, in that order. If either is found, it is assumed to be the desired value. This does mean that custom sections with the same name as an app setting will not be resolvable, but that’d be fairly easy to work around by scoping the names (eg. “appSettings.MySetting”). I’ll leave that as an exercise for the name-clash-apprehensive reader.

The second complication was harder to deal with. MEF doesn’t really give us the type of the property that is being satisfied (UPDATE: yes it does – keep reading below). Suppose, for example, you have a configuration setting to determine the number of allowed failed logons:

<appSettings> 
    <add key="maxRetryAttempts" value="3"/> 
</appSettings>

You would typically want to import this as an Int32, not as a String:

[Import("maxRetryAttempts")] 
public int MaxRetryAttempts 
{ 
    get; 
    set; 
}

However, MEF does not do any type conversions for us, and ignores any TypeConverterAttributes applied to the property. Hence, MEF will just throw an exception unless we do type conversion on its behalf.

To that end, I searched for a way to determine the type of the importing property. Alas, MEF does not appear to surface this information, for reasons that aren’t entirely obvious to me. It doesn’t seem like a bad thing for the export provider to be given some information about the type of the importing property, but maybe I’m missing something.

Anyways, what I was able to do is interrogate the import definition to see whether it is satisfied by various different export types (via MEF’s “ExportTypeIdentity” metadata). So I have a dictionary mapping the export type identity values to the logic necessary to convert a string to that type:

this.appSettingConverters = new Dictionary<string, Func<string, object>>() 
{ 
    { "System.String", v => v }, 
    { "System.Int32",    v => int.Parse(v, NumberStyles.Any, CultureInfo.InvariantCulture) }, 
    { "System.Double",   v => double.Parse(v, NumberStyles.Any, CultureInfo.InvariantCulture) }, 
    { "System.Single",   v => float.Parse(v, NumberStyles.Any, CultureInfo.InvariantCulture) }, 
    { "System.DateTime", v => DateTime.Parse(v, CultureInfo.InvariantCulture, DateTimeStyles.None) } 
}

If there are other types you want to support in your <appSettings/> section, then just add the appropriate mapping to this dictionary.

Note that this assumes that you don’t specify a custom contract type on the setting import, since that will alter the value in the “ExportTypeIdentity” metadata.

UPDATE: An Even Better Solution

As pointed out by Glenn in the comments, MEF does allow import metadata to be retrieved via its ReflectionModelServices APIs. This means we can get rid of the ugly mapping from export type identities to conversion logic and instead lean on Convert.ChangeType, passing it the actual CLR type of the importing property. Nice!

How It Is Used

At the end of the day, using this infrastructure requires that you first make the export provider known to the container:

var container = new CompositionContainer(catalog, new ConfigurationExportProvider(new FileConfigurationSource()))

Here I’m passing a FileConfigurationSource to the ConfigurationExportProvider. The FileConfigurationSource just uses the App.config file to get settings. You could conceivably use other sources, too. It’s the ConfigurationExportProvider that actually surfaces those configuration settings to MEF.

Once the container knows about the export provider, you can add your settings to your configuration file. These settings can be simple app settings or custom configuration sections:

<configSections> 
    <section name="customSection" type="AutoPropertyExporter.Configuration.CustomConfigurationSection, AutoPropertyExporter"/> 
</configSections> 

<appSettings> 
    <add key="Some.Setting" value="Hello"/> 
    <add key="Some.Int.Setting" value="321"/> 
</appSettings> 

<customSection customProperty="hello from custom config section"/>

Then you just need to import these settings in the consuming parts. As stated above, note that the Import attributes do not specify a custom contract type because that will break the export provider.

[Import("Some.Setting")] 
public string SomeProperty 
{ 
    get; 
    set; 
} 

[Import("Some.Int.Setting")] 
public int SomeIntSetting 
{ 
    get; 
    set; 
}  

[Import("customSection")] 
public CustomConfigurationSection CustomConfigurationSection 
{ 
    get; 
    set; 
}

And that’s it! MEF will take care of the rest.

There is a running sample application available for download here.

UPDATE 2: I’ve just uploaded a version using VS2010 project format and builds against .NET 4. It also adds support for importing configuration values into importing constructors.

WCF Channels, Faulting, and Dependency Injection

2010-01-09T12:33:00.001Z

The combination of WCF channel faulting behaviour and dependency injection (DI) makes for an interesting problem.

Suppose you have a simple service with contract ISimpleService. If you’re using DI, you’d like to be able to just declare your dependency as follows:

public class MyClass
{
    private readonly ISimpleService _simpleService;
    
    public MyClass(ISimpleService simpleService)
    {
        _simpleService = simpleService;
    }
}

You could then register your WPF channel instance with your DI container against the ISimpleService interface. Any dependency on the ISimpleService interface will be satisfied with that single WCF channel instance. Generally you want to share the channel throughout your application for performance reasons, but if you don’t want singleton semantics, most any DI container will support a means of returning a new instance of the channel for each resolution against the container.

However, A WCF channel transitions to a faulted state when a called service throws an exception that isn’t declared as part of its contract, or when a general communication error occurs (like the server goes down momentarily). Once faulted, a channel stays faulted and must be thrown away and recreated.

Consider what this means for our DI scenario. MyClass has a reference directly to a WCF channel. If that channel ever faults, it is unrecoverable. MyClass has no obvious means of recreating the channel. And if you’re using singleton semantics, even re-resolving the dependency won’t help you because you’ll get the same faulted channel back.

You can get around this problem to a certain extent by using a feature such as Unity’s static factory configuration. This allows you to provide logic that is called every time a dependency is resolved. Thus, your logic can cache channels until they fault and then replace them on the fly if and when they do.

But this relies on the dependency being re-resolved by the client code. This may be acceptable for web applications, where each request lives in its own little world, but it isn’t really a solution for desktop applications. In the above example, it would require MyClass to have a reference to its DI container, and to re-resolve the channel each time it requires it. That is error-prone, will spread virally throughout your code base, and forgoes much of the benefit of using DI in the first place.

So what, then, is the solution?

I believe the cleanest solution to this problem is to register a proxy onto the channel rather than the channel itself. This proxy is responsible for:

forwarding messages onto the WCF channel
detecting faulted channels and replacing it with a fresh one in as thread-safe manner as possible

I call it ChannelResurrectingProxy<T>, where T is the WCF service contract type. It is given a channel factory for T. Whenever it receives a message, it will first ensure that it has a channel and that it is not faulted. It will use the channel factory to resurrect the channel where necessary. It then forwards the message onto the channel and returns the result.

The attached project shows ChannelResurrectingProxy<T> in action. It demonstrates what happens when:

A service is called successfully
A service that throws an exception declared in its contract is called
A service that throws an exception not declared in its contract is called
A service that has out arguments is called
All services are called when there is no service host running (ie. the server is down)

All of these operations take place without re-resolving the dependency from the DI container. Thus, client code is blissfully unaware of the automatic resurrection of the channel. Of course, client code still needs to handle faults; it just doesn’t need to concern itself with the channel lifecycle anymore.

Download Example Project

Let StyleCop Emancipate you from Source Code Micromanagement

2009-10-15T20:22:00.001+01:00

My current project has stringent requirements across the board, including that of a highly consistent coding style. This is completely understandable because the client will be taking over maintenance and long-term support sometime after we’ve shipped. As such, they want to feel comfortable that their developers won’t be handed a steaming pile of code poo to polish.

One of the tools I thought might help us with this problem is StyleCop. This tool can analyze your code and flag any issues related to style. My initial suspicion was that StyleCop would annoy the heck out of me in about 10 seconds flat. It would whinge about missing file headers, the number of blank lines between code blocks, and even missing API documentation on private members. And it did do just that.

But something strange happened after a while: I stopped caring.

But not in a bad way. I just let the tool make these micro-decisions for me and instead concentrated on more important things like – you know – making the product actually work. If it told me I needed a blank line between my property getter and setter, I just did it – no questions asked. There was no nagging worry that I would do it differently elsewhere, or that some future developer on the project would, because the tool simply wouldn’t allow you to.

I’ve been able to get StyleCop integrated to an extent that I am very happy with:

It runs every time I build, whether it’s on my machine or the build machine. And it does not need to be installed on the developer’s machine (or the build server)
Any problems StyleCop reports prevent the build from succeeding (i.e. any problems are errors, not warnings)
Less important projects are excluded from StyleCop altogether, or have relaxed rules (such as for unit test projects, which don’t need API documentation)
Modifications to StyleCop settings are stored in central settings files and shared across projects. For example, I have a TestProjectSettings.StyleCop file, which contains settings for unit and integration test projects. If I disable a rule for one test project, it is disabled for all of them

The intent of this post is not to help you set StyleCop up with MSBuild. There are other resources out there that show you how to do that. I’m more interested in encouraging people to try this tool out. The more people that use it, the more it will be improved. And there is plenty of scope for improvement, as I’ll discuss shortly. If you’ve held off trying out this tool because you had bad experiences with it earlier in its short history, or because you think it has little to offer, perhaps it’s time to rethink.

So, what are the problems I’ve had using StyleCop? The biggest problem is that it’s lazy. It will happily report style problems to you any day of the week – even Sunday – but it refuses to lift a finger when it comes to rectifying said problems. This can be very irritating at first, but over time I have found myself preemptively and reflexively avoiding StyleCop’s wrath by writing code that conforms more and more to the default rule set.

The next problem is that of the default rule set. In adopting StyleCop I made it quite clear to my client that doing so implies either accepting the default rules, or spending a significant amount of time writing custom ones (time I don’t have). I can almost guarantee you won’t like all the default rules. Some of them will make you cringe, whilst others may make you downright furious. Of course, you can disable or tweak those rules that really get your goat.

Finally, StyleCop is particularly frustrating when you’re just wanting to try out a piece of code quickly in your project. There’s no built-in mechanism to demarcate a block of code as temporary and exempt it from style checks. Undef’ing the CODE_ANALYSIS symbol seems to do nothing, and SuppressMessage does not have any wildcard support. Therefore, you either need to move your scratch code into a temporary project, or waste time placating StyleCop.

UPDATE: As noted by wekempf in the comment below, you can wrap experimental code in a region with “generated code” in its name. This works even when you have the disallow all regions StyleCop rule enabled!

But for all its warts, I still feel somewhat liberated by StyleCop. No longer do I worry about whether I have the correct spacing, line breaks, or bracket placement in my source. I let the tool worry about that for me. And I feel as though spending the extra brain cycles on more important concerns is a win for both myself and my client.

Note that I am the only .NET developer on my project at the moment, so I can’t really comment on how well this would work with a team. I can’t really see it being an issue if everyone agrees that no rules should be disabled or suppressed without due justification and discussion. Some developers are sure to balk at the idea of having to conform to a particular style, but that’s only because it’s not their style. Heck, I was hesitant at first to make dramatic changes to my style (I prefer tabs, for example), but I quickly adjusted when I saw the benefits of the tool.

So next time you’re embarking on a new project, consider integrating StyleCop right from the get-go. The short term may be painful, but I think you’ll appreciate the decision in the long term.

VM Keyboard Rate Limited by Host

2009-09-22T10:39:00.001+01:00

Seems obvious when you think about it, but I thought it worth pointing out all the same. If you’re trying to up the ante on your keyboard settings inside a VM, be aware that their effect will be limited by the the keyboard settings on the host.

So if you set your VM’s keyboard to repeat crazy fast:

But your host is set to crazy slow:

The effective result in your VM is crazy slow. That’s because the host will only be passing on keyboard events to the VM in crazy slow mode, so the keyboard settings in the VM are essentially moot.

Ubuntu, SSH, and Remote Support

2009-08-24T18:00:00.001+01:00

Having a job in IT can sometimes be a curse. To mere mortals, the whole world of things that go beep is lumped together in a box labelled “voodoo”. Any issue even remotely related to computers can be directed your way. The typical geek probably finds themselves having to deal with document formatting problems, faulty mobile phones, and friends who can’t remember their email address. Can you imagine asking a cardiologist to examine your foot? No? Me neither.

My Mum – who runs Ubuntu – asked me for some help with her webcam the other day and I felt compelled to help her because:

She’s my Mum.
I got her onto Ubuntu in the first place and set it all up for her.
She’s my Mum.

The problem is that she lives in the sleepy town of Adelaide whilst I live in London, some 16,000 kilometres away.

Now, if we were using Windows I’d have used a service like CrossLoop to remote onto her machine^†. I’ve used it in the past to help my sister with her machine, and it was very good. Basically, CrossLoop works by acting as a middle-man between the two machines, so instead of connecting directly to each other, they connect to a CrossLoop server. This helps get around all the issues with firewalls and ports that the average computer user shouldn’t have to understand. Of course, it implies that you trust CrossLoop not to snoop on any data exchanged between the machines.

Alas, CrossLoop is Windows and Mac only^‡ – no love for the world of Linux. Moreover, I couldn’t find an alternative service at all for Ubuntu. To that end, I set about looking for something that would allow me to help my Mum. My requirements were simple enough:

Must be secure.
Must require no effort by my Mum except running a script. And when I say “no effort” I really mean that. Requiring any kind of router configuration or software configuration, for example, would be a deal-breaker. If I asked my Mum to open a port, she’d tell me it was too early in the day to drink (yes, even if it was 9PM).

After some reading and testing on my end, I settled on a solution using the most excellent SSH protocol. The key for me was SSH’s ability to set up a reverse connection. This allowed me to set up the SSH server and configure my router to do the port forwarding. Then I provided my Mum with a script that simply:

Kills any resident VNC session.
Starts up a new VNC session.
Sets up a reverse SSH tunnel to my machine, forwarding traffic on my port 9999 to the relevant VNC port on her side (5901). Having your own DNS entry helps here, but isn’t strictly required if you don’t mind validating the port in the script every time you use it (again, not an option for my Mum).

Once she runs that script, I can run a VNC client and connect to port 9999 on my local machine. By virtue of the SSH tunnel, I’m actually connecting to port 5901 on her machine, which is the VNC session. Magic!

The whole setup can be depicted graphically as follows (click to enlarge):

So there you have it. When my Mum has issues, she double-clicks a file on her desktop, enters a password (although you can use keys instead), and I can then connect to her desktop and hopefully sort it out. Now you, too, can provide remote support for your Mum’s Ubuntu installation.

Now all I have to do is fix her foot – I mean, webcam!

^† OK, OK, Linux haters – perhaps if my Mum was using Windows the webcam would be working just fine and this whole post would be moot. Instead I might be posting about how I had to rescue her machine from the clutches of malware.

^‡ OK, OK, Linux and Windows haters – perhaps if my Mum was using a Mac I’d be able to use CrossLoop and this whole post would be moot. Instead I might be posting about how I had to loan my Mum some money so she could buy milk and bread.

Addendum: I had an issue with the keyboard mappings with VNC. Basically, I would type “abcd” and would get “asdf” on the remote machine. Turns out this is a known issue and I found this blog post on the subject. It was a comment by dcatdemon on that post that helped me:

Edit your $HOME/.vnc/xstartup
Put the line "export XKL_XMODMAP_DISABLE=1" before your gnome-session
Restart vncserver

Note to Self: regarding the actual webcam, I had to recompile and reinstall the driver. When I set up Ubuntu originally for Mum I had to manually compile the driver because there was no built-in support for her webcam. Presumably, the latest kernel update had somehow broken backwards compatibility and the driver was no longer successfully being loaded. So I removed the old .ko driver binary from /lib/modules/kernel*/drivers/media/video/usbvideo/ and then recompiled and reinstalled according to here.

I suppose this may happen after future kernel updates, too. Lucky I have that support script all set up!

Truss V1.0.0.0 Released

2009-06-20T13:48:00.001+01:00

I have just released version 1 of Truss, a binding framework for POCOs. Truss allows you to bind together arbitrary .NET objects regardless of your choice of UI platform, or in the absence of a UI altogether.

Amongst its features, it provides support for bindings that use “magic strings” to specify property paths, as well as lambda expressions for compile-time checked bindings. Here’s a very simple example to whet your appetite:

var parent = new Person();
var child = new Person();
var bm = new BindingManager();

//bind the parent's savings to the child's inheritance
bm.Bindings.Add(new TypedBinding<Person, Person>(parent, p => p.Savings, child, c => c.Inheritance));

There are a number of scenarios I intend Truss to address, both now and with future enhancements:

Keeping related view models POCOs in sync with each other
Keeping related business objects in sync with each other
Provide a strong alternative to the limited binding support in Winforms, thus facilitating clean MVVM development in Winforms

You can download Truss source, binaries, and comprehensive documentation from here. Please direct any feedback my way.

Search and Highlight Text in an Arbitrary Visual Tree

2009-06-11T19:32:00.001+01:00

Download Example Project

A while back I answered this question on stackoverflow and have been meaning to elaborate on my answer ever since with a more comprehensive blog post. The question is about how to highlight some text in the UI when the user enters some search text. I thought I’d extend the concept into a clean, generic solution as far as I could and share it here.

My requirements are pretty straightforward:

Provide a search box in which the user can enter some text.
Highlight all matching text in the window, regardless of where it appears in the visual tree.

I was able to pull this off to an extent I am satisfied with. See the screenshot to the left. The user can enter some text in the top-right search text box, and then hit enter (or click the magnifying glass). Then all matching text is highlighted anywhere in the visual tree.

After an initial approach that relied on reflection in order to highlight content elements (ugh!), Marlon Grech kindly passed my question about how to do this more cleanly onto Dr. WPF and Jamie Rodriguez, who pointed me in the right direction (thanks guys!).

The basic approach I ended up using is:

Traverse the visual tree recursively, looking for IContentHosts and DocumentViewerBases. For DocumentViewerBases, extract the IContentHosts corresponding to each page.
For each IContentHost, search through its HostedElements collection to find any Runs.
For each Run, inspect its Text to determine whether the search term matches.
If the search term matches, use some TextPointer trickery to determine the bounding rectangle of the text.
Use a Canvas to lay out all semi-transparent rectangles on top of the application window, thus highlighting the matches.

There are a few problems that I’m aware of:

If the matching text spans multiple lines, the bounding rectangle isn’t correctly calculated. You could use IContentHost.GetRectangles to calculate all bounding rectangles correctly, but I just haven’t bothered to do so for the purposes of this post.
It doesn’t work for all content element hosts, such as FlowDocumentScrollViewer, because they don’t inherit from DocumentViewerBase. I suspect it’s probably not too hard to add support for them, but again I haven’t bothered to do so for this example.
It’s quite slow when the search term is short and frequently matched (as an example, try searching for “a”).

So the approach isn’t perfect, but this was an experiment more than anything else. I think a real application would want search support more intrinsic rather than relying on a generic mechanism like this. That said, there are bound to be some practical applications of the general technique used here.

PS. You may have noticed a lack of TMNT-related material in my sample this post. Unfortunately, my Windows Home Server recently died, which has prevented me from continuing to watch the series and has let my obsession waver somewhat. A replacement server is due next week, so expect more green reptile-based content soon!

Download Example Project

MVVM Infrastructure: ActiveAwareCommand

2009-05-07T13:03:00.001+01:00

Download Example Project

This post is part of a short series I am doing on MVVM infrastructure. In this series, I will share some thinking and code that has helped to produce cleaner, simpler MVVM code in my applications.

Related posts:

In my last post I discussed the DelegateCommand, which allows you to associate a WPF command directly with logic in your view model. In this post I am going to talk about the ActiveAwareCommand, which does exactly the same thing, but it enables you to widen the scope from which the command is used.

The DelegateCommand works great when the command source (such as a Button) has a one-to-one relationship with the view model. For example, recall the customers example from the previous post (see right). The Add and Delete buttons are defined in the CustomersView. Since the CustomersView has a one-to-one relationship with the CustomersViewModel, the Buttons also have a one-to-one relationship.

But suppose we wanted to change the Add and Delete buttons to MenuItems, and re-use those MenuItems across multiple views. Essentially, we want to change the one-to-one relationship between command source and view model to a one-to-many relationship. With DelegateCommands, the MenuItems would be intimately tied to a particular view. Therefore, the best effort would result with multiple Add and Delete entries in the Menu – one for each view that supports adding and deleting items. We’d have to distinguish the MenuItems with unique headers, such as “Add Customer” and “Add Order”. Obviously, that would result in a horrible user experience.

ActiveAwareCommand provides a solution to this little dilemma by maintaining a list of potential targets for the command, and only interacting with the active target (if there is one). Each potential target is an implementation of IActiveAware^†, and the ActiveAwareCommand uses the IsActiveChanged event on this interface to track the active target. The ActiveAwareCommand belongs to a single view model but maps to any number of command sources, thus fulfilling the one-to-many relationship we seek.

The IActiveAware interface gives you the freedom to use whatever logic you like to determine whether the potential target is active. However, it is likely that you will most often use focus to activate an item. To that end, the FocusActiveAwareAdapter wraps a FrameworkElement and gives you an implementation of IActiveAware whose IsActive property is changed to true when the FrameworkElement gets focus, and false when it loses focus.

Generally speaking, the steps for using an ActiveAwareCommand are:

Construct an instance of ActiveAwareCommand, usually as a public static readonly member of a view model class.
In your view model class, expose a property that allows the view to provide an IActiveAware implementation to monitor. This property should register and unregister the IActiveAware implementation with the ActiveAwareCommand.
In your view, pass an implementation of IActiveAware to the view model when the view loads. Usually this will involve constructing an instance of FocusActiveAwareAdapter that wraps the view.
Bind to the ActiveAwareCommand from a shared piece of screen real estate, such as the main menu or application ribbon.

To demonstrate the use of ActiveAwareCommand, I put together another TMNT-related sample project (I’m totally scoping the 2003 era series, like, start to finish at the moment, dudes). In it, the user is able to edit the details of any number of characters in separate tabs. Each character can be saved independently of the others from both the main menu and a tool bar button. Since an ActiveAwareCommand is used for the save functionality, the command is correctly routed to the active tab without any need for manual redirection by the views.

I may have gone a bit overboard with the sample project. I initially started out writing a simpler example, but I found myself wanting something a bit more substantial and real-world. Anyway, feel free to ignore most of the code and just concentrate on the parts pertinent to this post.

I think that about wraps up my series on MVVM infrastructure – for now at least. I hope it has been of some use. I’ve got some other things in mind that I want to blog about, but I’m on leave in Australia through to June. Until then…

† Prism has a similar interface, but it is used for different purposes. Same goes for Prism’s CompositeCommand, which is used to broadcast a command to multiple handlers, as opposed to unicasting only to the active handler.

Download Example Project

MVVM Infrastructure: DelegateCommand

2009-04-19T17:40:00.001+01:00

Download Command.cs
Download DelegateCommand.cs
Download DelegateCommandExample.zip

This post is part of a short series I am doing on MVVM infrastructure. In this series, I will share some thinking and code that has helped to produce cleaner, simpler MVVM code in my applications.

Related posts:

In my last post I discussed my ViewModel base class. In this post I’m going to start showing you some infrastructure around commanding.

WPF's commanding support enables you to hook up UI interactions with code without tightly coupling the two. User actions are abstracted into implementations of WPF’s ICommand interface, which are then associated with controls that implement ICommandSource. Essentially, it's a layer of indirection. The controls in the UI aren't intimately aware of the command logic they are connected with, and the command logic isn't aware of the controls it will be associated with.

When starting out with WPF commanding, you will soon come across the RoutedCommand class. This particular command is yet another layer of indirection, in that its execution logic involves finding something to execute and calling that! Starting with the focused element, it searches up the visual tree for an element that has a matching CommandBinding in its CommandBindings collection. If the RoutedCommand finds a matching CommandBinding, it executes that CommandBinding's Executed delegate.

Routed commands work great in certain scenarios, and are prevalent in WPF. Indeed, the only concrete ICommand implementation that comes with WPF is the RoutedCommand (and its subclass, RoutedUICommand). Unfortunately, this has caused WPF commanding to become somewhat synonymous with RoutedCommands, which is not at all accurate.

The thing is, routed commands are not always a great fit for MVVM development. Typically the logic for your command execution belongs in the view model. For example, suppose you have a CustomersViewModel that maintains a list of CustomerViewModels, and you want to expose a command that deletes the selected customer. The logic for that command should reside in the CustomersViewModel, since it knows best what to do when a deletion is requested.

If you were to use a RoutedCommand, you would then need a CommandBinding somewhere in the UI in order to connect a visual element to the DeleteCustomerCommand. In our example, we would likely stick a CommandBinding in the CustomersView and associate it with the deletion command and methods on the view model. Without the CommandBinding, the RoutedCommand won't find a handler for the command and the Delete button will be forever disabled.

Using routed commands with MVVM ends up being messy, sub-optimal, and requires the view be more tightly coupled to the view model. And in some scenarios, it’s not even possible (I’ll discuss such a scenario in my next post). But the good news is, we don't have to use routed commands. All we need is an appropriate implementation of ICommand – one that is more conducive to MVVM development.

If you think about it, all we really want to do is have a command that – when executed – invokes a method in our view model. And when the command is queried for its executable status, it executes a different method in the view model. To continue our customer example, that command might be associated with a Button in our CustomersView. The availability of the command would be dependent upon the user first selecting a customer (you can't delete a customer if you don't know which customer to delete). The execution of the command might execute a DeleteCustomer method on the CustomersViewModel.

Sound simple? That's because it is! Far simpler than attempting to use routed commands for this scenario.

The command implementation I use is called DelegateCommand, simply because it invokes delegates when executing and querying executable status. Other people have different names for this type of command, the most common of which seems to be RelayCommand. That's fine - call it what you will.

Prism has a DelegateCommand too, which is almost exactly the same as this one. However, the reason I have my own is simply because we don't use Prism in our project^†, and it would be a large overhead to pull it in just for the sake of a class or two. Besides, if you're doing a non-composite WPF app, Prism may not be a good fit.

To create a DelegateCommand, you simply give it one or two delegates to use. If you give it only one delegate, the command is assumed to be always available. That is, ICommand.CanExecute() will always return true.

In our CustomersViewModel, we create the DelegateCommand as follows:

_deleteCustomerCommand = new DelegateCommand(DeleteCustomer, CanDeleteCustomer);

We then expose the command from a property in our view model:

public ICommand DeleteCustomersCommand
{
    get { return _deleteCustomerCommand; }
}

And bind to it in the view:

<Button Command="{Binding DeleteCustomersCommand}">Delete</Button>

It’s as simple as that. The delegates supplied to the DelegateCommand will be invoked at the appropriate times and our Delete button will only be enabled when a customer is selected. You can see all this and more in the download.

Incidentally, DelegateCommand inherits from a base Command class. That’s just to keep the code DRY with respect to other command classes I have, such as the ActiveAwareCommand. I’ll talk about that one in the next post.

† The application in question was built before Prism shipped, elsewise we would be.

Download Command.cs
Download DelegateCommand.cs
Download DelegateCommandExample.zip

MVVM Infrastructure: ViewModel

2009-04-07T18:41:00.001+01:00

Download ViewModel.cs

This post is part of a short series I am doing on MVVM infrastructure. In this series, I will share some thinking and code that has helped to produce cleaner, simpler MVVM code in my applications.

Related posts:

In this post, I'm going to show you a base class for view models I have imaginatively named ViewModel. This is by no means a complex class, but it's a fantastic time-saver when doing MVVM.

I had a few concerns at the fore-front of my mind when designing this class. Firstly, I wanted it to be extremely simple to use. When inheriting from it, I didn't want to have to worry about implementing specific constructors in my subclass or providing implementations of abstract members. It should be brain-dead simple to extend the ViewModel class.

Secondly, I was concerned about having too many members on the base class. Doing so could make it harder to discern those members of interest when working on subclasses. Essentially, I didn't want a lot of noise in the APIs, because that adds just that little bit of friction that can accumulate into a ball of pain.

Thirdly, I didn't want the class to impose too much on subclasses. They should be granted as much freedom of implementation as possible whilst still providing them with value. For example, subclasses should have the ability to provide their own implementation of equality.

Finally, I wanted to minimize the performance impact of leveraging this base class. I didn't want consumers to have to choose between a good view model design and performance. Ideally, they could have their cake and eat it, too. Of course, I'm not saying you can design your view models as fine-grained as you like without a thought for performance. I'm just saying I wanted to mitigate the risk.

As you'll see from the code, I think it's fair to say these goals have all been satisfied. The attached file includes API documentation, but the small size of the class means I can include it here, sans documentation:

public abstract class ViewModel : INotifyPropertyChanged 
{ 
    private readonly Dispatcher _dispatcher; 
    
    protected ViewModel() 
    { 
        if (Application.Current != null) 
        { 
            _dispatcher = Application.Current.Dispatcher; 
        } 
        else 
        { 
            //this is useful for unit tests where there is no application running 
            _dispatcher = Dispatcher.CurrentDispatcher; 
        } 

    } 

    [field:NonSerialized]
    public event PropertyChangedEventHandler PropertyChanged; 

    protected Dispatcher Dispatcher 
    { 
        get { return _dispatcher; } 
    } 

    protected virtual void OnPropertyChanged(PropertyChangedEventArgs e) 
    { 
        PropertyChanged.Raise(this, e); 
    } 

    protected void OnPropertyChanged(string propertyName) 
    { 
        OnPropertyChanged(new PropertyChangedEventArgs(propertyName)); 
    } 
}

There are really only two responsibilities taken on by this class:

Implement INotifyPropertyChanged.
Provide access to a Dispatcher.

The OnPropertyChanged overrides allow subclasses to easily raise the PropertyChanged event (incidentally, that call to PropertyChanged.Raise is by virtue of my library The Helper Trinity). For example, a subclass might do so like this:

public string Name 
{ 
    get { return _name; } 
    set 
    { 
        if (_name != value) 
        { 
            _name = value; 
            OnPropertyChanged("Name"); 
        } 
    } 
}

The Dispatcher property allows subclasses to gain access to the current Dispatcher, which makes it much easier to perform work to a background thread and then synchronize the results with the UI. Importantly, a new Dispatcher for the current thread is assigned if no WPF application is running. This makes unit testing much easier as there will always be a Dispatcher available via this property.

So that's it really. Nothing much to it, and that's the way I like it. Next up in this series, we'll start looking at the infrastructure I have around commanding.

Download ViewModel.cs

MVP

2009-04-03T21:03:00.001+01:00

I'm very pleased to announce that I have been awarded MVP for 2009 in Client Application Development. This is the first MVP award I have received. Being notified on the 1st of April was a little disconcerting, but against all odds it was not a hoax.

I look forward to continued involvement in the developer community over the coming years.

WPF for LOB

2009-04-02T20:40:00.001+01:00

Here’s some great news for anyone doing WPF in LOB applications. Karl Shifflet and Jaime Rodriguez are travelling the World (well OK, parts of the World) to present a training course on WPF and MVVM in real-world applications.

This is an awesome opportunity and I wish I could be there. As luck would have it, I will be on leave in Australia precisely when they’re presenting in the UK :(

Oh, and did I mention it’s FREE!?

Get the full details here.

View Models: POCOs versus DependencyObjects

2009-03-26T18:40:00.001Z

This post is part of a short series I am doing on MVVM infrastructure. In this series, I will share some thinking and code that has helped to produce cleaner, simpler MVVM code in my applications.

Related posts:

POCOs versus DependencyObjects
ViewModel
DelegateCommand
ActiveAwareCommand

If you're leveraging the MVVM pattern in your WPF/Silverlight development, you will quickly be faced with a decision regarding the implementation of your view models: should they be DependencyObjects, or POCOs (Plain Old CLR Objects)? I've seen and worked with applications that use both of these options.

This post is intended to discuss these two options. It certainly won't touch on all issues and nuances of either option, but it will cover the main ones I have found to be problematic. I will order them from least significant to most.

Performance

I was hesitant to even mention this one because I haven't done any measuring and haven’t found it to be a problem at all. There is a theoretical performance benefit to using DependencyObjects for view models for a couple of reasons:

Lower memory usage.
Faster binding performance.

The former assumes your view models have a lot of properties, and that those properties tend to take on their default values. WPF’s dependency object system is optimised for this case. Your typical WPF control has dozens or even hundreds of properties, most of which are set to their default value. Extra memory is only used by properties if they take on a non-default value. If your view models follow a similar pattern then you might get some memory usage benefits from using DependencyObjects. But I'd also be questioning your view model design if that was the case.

The second point is more relevant, since the primary job of a view model is to provide properties to which the view can bind. WPF's binding system supposedly performs better when binding to DependencyObjects than to CLR properties. That may well be the case (again, I haven't measured), but the difference must be negligible because this has not proven to be a problem for me thus far.

Property Change Notification in a Related View Model

Suppose you have two view models that are related. For example, a ParentViewModel and ChildViewModel. Let’s say that the ChildViewModel has a reference to a ParentViewModel. When the Savings property on the ParentViewModel changes, we want to update the Inheritance property on the ChildViewModel. Using DependencyObjects as view models, we can simply use data binding to achieve this:

//this code is in the ChildViewModel constructor
var binding = new Binding("Savings") { Source = parent};
BindingOperations.SetBinding(this, ChildViewModel.InheritanceProperty, binding);Using POCOs we need to do a little more work. Typically your POCO view models will implement INotifyPropertyChanged, so the code would look more like this: 

//this code is in the ChildViewModel constructor
parent.PropertyChanged += delegate(object sender, PropertyChangedEventArgs e)
{
    if (e.PropertyName == "Savings")
    {
        Inheritance = parent.Savings;
    }
};

Neither of these options is particularly appealing to me, but the binding approach with DependencyObjects is more flexible and less typing. Both suffer from magic strings ("Savings", in this case).

I recognised this as a problem with POCO view models a while back and have been busy working on a library that solves it. To whet your appetite, using my library would allow you to do this with any POCOs:

//this code is in the ChildViewModel constructor
var binding = new TypedBinding<ParentViewModel, ChildViewModel>(parent, x => x.Savings, this, x => x.Inheritance);
bindingManager.Bindings.Add(binding);

Note the strongly-typed binding using lambda expressions. Note also that I'm planning an even terser, fluent interface. Something like:

bindingManager.Bind(parent).Property(x => x.Savings).To(this).Property(x => x.Inheritance);

Serialization of View Models

Sometimes you will want to serialize your view model. For example, you might want to implement the IEditableObject interface so that changes to your view model can be rolled back. An easy way to do this is to serialize a snapshot of your view model and then roll back if necessary:

[Serializable]
public class MyViewModel : IEditableObject
{
    [NonSerialized]
    private object[] _copy; 

    public MyViewModel()
    {
        Name = string.Empty;
    } 

    public int Age { get; set; } 

    public string Name { get; set; } 

    public void BeginEdit()
    {
        //take a copy of current state
        var members = FormatterServices.GetSerializableMembers(GetType());
        _copy = FormatterServices.GetObjectData(this, members);
    } 

    public void CancelEdit()
    {
        //roll back to copy
        var members = FormatterServices.GetSerializableMembers(GetType());
        FormatterServices.PopulateObjectMembers(this, members, _copy);
    } 

    public void EndEdit()
    {
        //discard copy
        _copy = null;
    }
}

This works fine for POCO view models, but not so for DependencyObjects. Recall that for an object to be serializable (and I'm talking strictly about IFormatter-based serialization here), it and all its subclasses must be marked with the Serializable attribute.

DependencyObjects are not marked as serializable.

Incidentally, you might instead follow the pattern where you wrap your data inside a serializable struct and just serialize/restore that struct instead of the view model itself. That works great for POCOs, but – yet again – you will run into headaches if you use DependencyObjects.

And there are other reasons you might want to serialize your view model. Perhaps you want to clone it. Or perhaps you want to save certain view model objects over application restarts. DependencyObject-based view models will cause you grief when this need arises. Basically, your only option is to implement serialization surrogates, or use a non-IFormatter-based serialization mechanism.

Equality and Hashing

It is often useful to compare view models for equality, or stick them in a dictionary. For example, suppose you have a ReportsViewModel that is responsible for managing and exposing a set of ReportViewModels (note the plural versus singular in those names). Each ReportViewModel contains the name of the report, the parameters to the report, and the results of its execution:

Now suppose you'd like to cache report executions. If the user runs the same report with the same parameters, you'd like to just give them the existing results. To achieve this, you'd naturally attempt to override the Equals() and GetHashCode() methods in the ReportViewModel class (and implement IEquatable<ReportViewModel> if you're thorough). But if the ReportViewModel class inherits from DependencyObject, you'll find that you can't.

The DependencyObject class overrides and seals both the Equals() and GetHashCode() methods.

This inability to redefine equality in your view models is both annoying and limiting in certain scenarios. There may be ways around the problem. For example, you could implement a class that implements IEqualityComparer<ReportViewModel> and use it where appropriate. However, this can quickly lead to a mess and anti-DRY code base.

Of course, if your view model is a POCO, it won't suffer from this problem. You'd just provide the most appropriate implementation of equality inside your view model class.

Thread Affinity of View Models

One of the responsibilities your view models will typically take on is that of doing heavy work on a background thread. For example, suppose you have a refresh button in your UI that causes a heap of widget data to be loaded from the database and displayed in a list. You'd hardly want the UI to hang while the database access is taking place, so you decide to put the work in a background thread:

public class MyViewModel
{
    //this gets called when the user clicks the refresh button - we'll worry about how that happens in a later post
    public void LoadWidgets()
    {
        //do the heavy lifting in a BG thread
        ThreadPool.QueueUserWorkItem(delegate
        {
            var widgets = new List<Widget>();
            //pretend I execute a database query here, would you kindly?
            var dataReader = command.ExecuteReader(); 

            while (dataReader.Read())
            {
                widgets.Add(new WidgetViewModel(dataReader["Name"]));
            } 

            //now we have all our widgets read from the DB, so assign to the collection that the UI is bound to
            Dispatcher.Invoke(delegate
            {
                Widgets.Clear();
                Widgets.AddRange(widgets);
            });
        });
    }
}

All we're doing here is doing as much work on a background thread as we can. Only at the last step do we switch to the UI thread to update the collection that the UI thread is bound to (and with the right infrastructure, even that would be optional).

Again, this is great for POCO view models, but falls flat on its face for DependencyObjects.

A DependencyObject has thread affinity - it can only be accessed on the thread on which it was created.

Since we're creating a bunch of WidgetViewModels on a background thread, those view models will only be accessible on that thread. Therefore, as soon as the UI thread tries to access them (via bindings) an exception will be thrown^†.

The only option here is to construct and populate each view model on the UI thread. This is ugly, error-prone, and can negate much of the benefit of doing the work on a background thread in the first place. If we need to create many view models, suddenly the UI thread spends much of its time constructing and initialising those view models.

Code Readability

You'll notice that all of these problems can be worked around, and I don't dispute that. However, all those workarounds result in an incomprehensible mess of code. One of the most important qualities of code is its readability. Using DependencyObjects as view models causes an explosion of supporting code and workarounds that obscure the intent of the code. What's more, all these workarounds gain you . . . nothing.

To me, this is the final nail in the coffin for DependencyObjects as view models. I want my view models to be as readable and maintainable as the XAML I get from using MVVM in the first place. Rather than sweep The Ugly from the view to the view model, I'd much prefer to banish it entirely.

Conclusion

I think the advantages of POCO view models over DependencyObject view models are clear and convincing. Moreover, the disadvantages of using POCOs are practically zero. As such, I always use the POCO option in my projects. That said, all the problems I mentioned can be worked around, and you may have a convincing argument to do so (please let me know in the comments if you do). But, for the here and now, I will be sticking with POCOs for my view models.

In the next two or three posts, I will be sharing some infrastructure I have put together for MVVM applications, starting with a base ViewModel class.

† Note that WPF does do some auto-marshalling for us with simple properties. However, it cannot automatically marshal changes to collections, so you will inevitably end up wanting to create non-trivial DispatcherObjects on the UI thread.

MultiKeyGesture

2009-03-16T19:30:00.001Z

Download the Solution

A colleague recently asked whether it was possible to invoke a WPF Command when the user presses a sequence of keys. As an example, consider the Format Document command in Visual Studio, which is generally mapped to Ctrl+K, D.

In WPF, a Command can be invoked via "input gestures" in a couple of different ways:

When creating a RoutedCommand, you can add any number of InputGestures to the InputGestures collection. Adding an InputGesture to this collection ensures that the Command will be executed (if it can be) when that gesture is performed by the user.
Via the UIElement's InputBindings collection. Adding an InputBinding to this collection ensures that a certain InputGesture will execute a certain Command against that UIElement.

WPF's built-in KeyGesture class is an InputGesture subclass that recognises a gesture based on keyboard input. The problem is, its definition of "gesture" is a single keypress. What I'd like to do is treat multiple keypresses as a single gesture, and KeyGesture does not support that.

Enter my MultiKeyGesture class. At first I thought I'd subclass InputGesture rather than KeyGesture, since the KeyGesture constructors reflect the single-key assumption. However, I found I had little choice but to subclass KeyGesture because the built-in WPF MenuItem control treats it as a special case in determining the text to display for the shortcut string. I could manually set the InputGestureText of the MenuItem, but I just couldn't be bothered for the purposes of this post.

Never mind though, because I can simply pass in Key.None to the KeyGesture constructor and override its matching logic:

public MultiKeyGesture(IEnumerable<Key> keys, ModifierKeys modifiers, string displayString)
    : base(Key.None, modifiers, displayString)
{
    _keys = new List<Key>(keys); 

    if (_keys.Count == 0)
    {
        throw new ArgumentException("At least one key must be specified.", "keys");
    }
} 

public override bool Matches(object targetElement, InputEventArgs inputEventArgs)
{
    ...
}I

n other words, I'm only inheriting from KeyGesture so that our particular gesture implementation gels with other WPF classes that make annoying assumptions and break the Liskov substitution principle.

Notice from the constructor that the MultiKeyGesture class takes an enumeration of Keys. In order for a match to occur, the user must type in all of those keys (in order, of course). Generally, you would have a maximum of two keystrokes, but the sky really is the limit here. You could make the user type in "Ctrl+A, p, r, i, l, O, n, e, i, l, l, i, s, h, a, w, t" before your super-secret command is executed. You'd be pretty childish if you did that, but you could.

The Matches() method is where all the magic happens. It is this method that determines whether the user input matches the keys in the Keys collection. It does this with a mini state machine. As input is received, one of three things can occur:

No match. The user entered the wrong key or paused too long between keystrokes. The index into the Keys collection is reset back to zero and the method returns false.
Partial match. The user entered a matching key but not all keys have been entered yet. The index into the Keys collection is incremented and the method returns false (but marks the RoutedEvent as handled).
Full match. The user entered the final matching key in the Keys collection. The index into the Keys collection is reset back to zero and the method returns true.

That's it really. All the usual disclaimers apply about blog-quality code, but it does at least show that the scenario is possible in WPF.

If you look at the code, you'll notice a couple of other classes:

MultiKeyBinding
MultiKeyGestureConverter

These aren't strictly necessary unless you want UIElement.InputBindings and XAML integration respectively. MultiKeyBinding is used to map a MultiKeyGesture to a particular Command for a UIElement (in XAML in this case, but could also be in code, of course):

<TextBox x:Name="_textBox">
    <TextBox.InputBindings>
        <local:MultiKeyBinding Command="{x:Static local:Commands.Secret}"            Gesture="Ctrl+A,p,r,i,l,O,n,e,i,l,l,i,s,h,a,w,t"/>
    </TextBox.InputBindings>
</TextBox>

MultiKeyGestureConverter is used to parse the Gesture attribute in the XAML into a MultiKeyGesture for the MultiKeyBinding.

Note that I didn't put much effort into these supporting classes at all. They are bare-bones to get the demo working.

Download the Solution

Unselectable, Interactive Items in a Selector

2009-03-07T10:54:00.001Z

Download the Solution

Disabling an item in a Selector (such as a ComboBox) is easy once you understand that each item is automatically wrapped in its own container, and that you can apply a style to that container.

Suppose you have a view-model that represents a customer:

public class CustomerViewModel : ViewModel
{
    private string _name; 

    public string Name
    {
        get { return _name; }
        set
        {
            if (_name != value)
            {
                _name = value;
                OnPropertyChanged("Name");
                OnPropertyChanged("IsEnabled");
            }
        }
    } 

    public bool IsEnabled
    {
        get
        {
            return !Name.StartsWith("Kent ");
        }
    }
}

You can bind to the IsEnabled property from the item container's style thusly:

<ComboBox ItemsSource="{Binding Customers}" DisplayMemberPath="Name">
    <ComboBox.ItemContainerStyle>
        <Style>
            <Setter Property="UIElement.IsEnabled" Value="{Binding IsEnabled}"/>
        </Style>
    </ComboBox.ItemContainerStyle>
</ComboBox>

Then any Customer's who share my Christian name will be completely disabled:

The user is unable to select the disabled items with the keyboard or mouse, nor can they interact with them in anyway (eg. if there was a Button in the ItemTemplate of the ComboBox, the Button would also be disabled).

But what if I want to allow the user to interact with an item in the ComboBox, but not allow them to select it via the keyboard or mouse? There are numerous reasons you might want to do this, but my use case was as follows (this is a financial application):

User can select from a number of market-related times (such as Open, Closing, Live, T - 1, T - 2 etcetera) in a ComboBox
User can alternatively click on a specific date in a Calendar that is inside the same ComboBox
When the user selects a date in the Calendar, the SelectedValue of the ComboBox reflects this fact
The user cannot manually (via keyboard or mouse) select the interactive calendar item in the ComboBox
In addition to manually selecting values, the user can type values in the ComboBox (ie. it is editable). For example, they might type "Open", "T - 1", or a specific date, such as "31/12/2004"
When typing in dates, the calendar should "scroll to" the correct month for the date entered
Future dates are not permitted

First of all let me say that it might be possible to pull this off by re-templating the ComboBox such that its Popup displays all items and then a Calendar below the items. However, this has some serious disadvantages:

re-templating a complex control such as ComboBox is time-consuming and error-prone
re-templating needs to be done for each theme supported by the application, and for each control we want to use this technique in (what if I want to change from a ComboBox to a ListBox, for example)
I really want the interactive item in the ComboBox to be programmatically selectable. This will be particularly useful for those who want to use this technique with a ComboBox that isn't editable

It's time to set the stage a bit. Please bear with me a little here. Here are the view models I threw together to get myself started solving this problem:

The view models take care of various details such as parsing and validating any text entered by the user. I could then put together some minimalistic data templates to render these view models:

<!-- explicit points in time are rendered as a Calendar so that the user can choose the point in time they want -->
<DataTemplate DataType="{x:Type local:ExplicitPointInTimeViewModel}">
    <wpf:Calendar SelectedDate="{Binding SelectedValue, Mode=TwoWay}"/>
</DataTemplate> 

<!-- financial times are rendered as an editable combo box listing all times -->
<DataTemplate DataType="{x:Type local:FinancialTimesViewModel}">
    <ComboBox x:Name="_comboBox" ItemsSource="{Binding Items}" IsEditable="True" Text="{Binding Text, ValidatesOnDataErrors=True}">
        <ComboBox.ItemContainerStyle>
            <Style TargetType="ComboBoxItem">
                <!-- ensure relevant combo box items are disabled -->
                <Setter Property="IsEnabled" Value="{Binding Converter={StaticResource IsEnabledConverter}}"/>
            </Style>
        </ComboBox.ItemContainerStyle>
    </ComboBox>
</DataTemplate>

Finally, I put a ContentControl in my Window and stuck a FinancialTimesViewModel in it:

var viewModel = new FinancialTimesViewModel();
viewModel.Items.Add("Live");
viewModel.Items.Add("Open");
viewModel.Items.Add("Closing");
viewModel.Items.Add("T - 2");
viewModel.Items.Add("T - 3");
viewModel.Items.Add(new ExplicitPointInTimeViewModel());
_contentControl.Content = viewModel;

Running this we can see that the templates are being used to render the view models:

As expected, the Calendar is completely disabled and useless so far as our use case goes. The first thing I tried to get around this was to just re-enable a child control inside the DataTemplate:

<DataTemplate DataType="{x:Type local:ExplicitPointInTimeViewModel}">
    <ContentControl IsEnabled="True">
        <wpf:Calendar SelectedDate="{Binding SelectedValue, Mode=TwoWay}"/>
    </ContentControl>
</DataTemplate>

However, this had no effect. It was time to do some investigative work (otherwise known as Reflector) to determine how the ComboBox was making its decision to disable the item. I found this method in ComboBox that determines whether an item is selectable:

private bool IsSelectableHelper(object o)
{
    DependencyObject obj2 = o as DependencyObject;
    return ((obj2 == null) || ((bool) obj2.GetValue(UIElement.IsEnabledProperty)));
}

So if it's not a DependencyObject, the item is selectable. And if it is, the IsEnabled property is used to determine its "selectability".

But wait - we changed the IsEnabled property of the ContentControl within the template and it didn't enable its children. That's because IsEnabled doesn't get to make the final decision about whether a UIElement is enabled or not. From MSDN:

Note that this property is influenced by class-specific implementations of IsEnabledCore on particular elements, often at runtime. Therefore, the default value listed here is sometimes not effective.

Examining UIElement further, I found that the IsEnabled property was being coerced to false if any ancestor was disabled. That makes perfect sense really. You'd hardly want to have to manually disable all the children of a Panel when you disable the Panel itself. It’s much nicer that you can just disable the Panel and all children become disabled.

So what to do? I needed a control that didn't consider the IsEnabled state of any parent, and that's when I wrote the AlwaysEnabledControl:

public class AlwaysEnabledControl : Border
{
    static AlwaysEnabledControl()
    {
        //override IsEnabled to coerce to true rather than considering the enabled state of the parent combo box item
        IsEnabledProperty.OverrideMetadata(typeof(AlwaysEnabledControl), new FrameworkPropertyMetadata(true, IsEnabled_Changed, CoerceIsEnabled));
    } 

    private static void IsEnabled_Changed(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
    {
    } 

    private static object CoerceIsEnabled(DependencyObject dependencyObject, object value)
    {
        //we're always enabled
        return true;
    }
}

As you can see, this control overrides the coercion logic in UIElement such that it is always enabled. Now, if I can wrap my Calendar in this baby:

<DataTemplate DataType="{x:Type local:ExplicitPointInTimeViewModel}">
    <local:AlwaysEnabledControl>
        <wpf:Calendar SelectedDate="{Binding SelectedValue, Mode=TwoWay}"/>
    </local:AlwaysEnabledControl>
</DataTemplate>

And here's what I get at runtime:

Hooray! Our Calendar is now enabled and the user can interact with it. However, there are some problems:

As evident in the screenshot, the Calendar gets highlighted when the user mouses over it, which looks ugly
Not evident in the screenshot, the user can select the ComboBoxItem containing the Calendar by using the keyboard or mouse

In reality I dealt with the second problem first because it was a deal-breaker. However, I'll talk about the first problem first here because it's conceptually easier.

I considered a couple of different solutions to the selection highlight problem. My first thought was to override the SystemColors.HighlightBrushKey and SystemColors.HighlightTextBrushKey resources for the ComboBoxItem containing the Calendar. The ComboBoxItem template uses these resources to look up Brushes when highlighting itself.

The problem was, I couldn't override these resources for individual ComboBoxItems - at least, not from within the XAML. I could override for all ComboBoxItems like this:

<ComboBox.Resources>
    <SolidColorBrush x:Key="{x:Static SystemColors.HighlightBrushKey}">Red</SolidColorBrush>
</ComboBox.Resources>

But attempting to override at the ComboBoxItem failed:

<ComboBox.ItemContainerStyle>
    <Style TargetType="ComboBoxItem">
        <Setter Property="Resources">
            <Setter.Value>
                <ResourceDictionary>
                    <SolidColorBrush x:Key="{x:Static SystemColors.HighlightBrushKey}">Red</SolidColorBrush>
                </ResourceDictionary>
            </Setter.Value>
        </Setter>
    </Style>
</ComboBox>

This fails at runtime, and is not really what I want to do anyway. What I want is to selectively inject resources into the ComboBoxItem's Resources collection. I could not figure out how to do this from XAML, so I decided to ponder other solutions.

The solution ended up being reasonably simple. I added these Setters to the ComboBoxItem Style:

<!-- ensure we can't see the highlighting when we mouse over any always-enabled control -->
<Setter Property="HorizontalContentAlignment" Value="Stretch"/>
<Setter Property="VerticalContentAlignment" Value="Stretch"/>
<Setter Property="Margin" Value="0"/>
<!-- most items require some padding, but the calendar control should not have any -->
<Setter Property="Padding">
    <Setter.Value>
        <Binding Path="." Converter="{StaticResource PaddingConverter}">
            <Binding.FallbackValue>
                <Thickness>2,0,2,0</Thickness>
            </Binding.FallbackValue>
        </Binding>
    </Setter.Value>
</Setter>

What we're doing here is making sure the content in the ComboBoxItem stretches across the entire expanse of the ComboBoxItem. Therefore, even if the interactive item is highlighted, we won't be able to see the highlighting. Of course, I need to also give the interactive item a non-transparent Background:

<local:AlwaysEnabledControl Background="LightGray">
    <wpf:Calendar SelectedDate="{Binding SelectedValue, Mode=TwoWay}"/>
</local:AlwaysEnabledControl>

Now running the application we see this:

It won't win any beauty contests, but we're edging closer and closer to the desired behaviour.

The last big problem that required solving is the fact that the user can still select the interactive item via the keyboard or mouse. This is counterintuitive and annoying for the user if they actually click just outside the Calendar.

It seems wrong that the ComboBoxItem is considered selectable given that it has been disabled (remember, it's just the contents inside the ComboBoxItem that are enabled). The key to solving this problem is understanding that the ComboBox executes different selection logic based on whether the drop-down is open or not. Indeed, if I run the application at this point and try to select the interactive item without opening the ComboBox drop-down, I can't. But if I open the drop-down first, I can cursor down until the Calendar is selected.

When the drop-down is open, the ComboBox actually delegates to an internal method on ItemsControl to select the next item. That method (ItemsControl.NavigateByLine) uses keyboard navigation to determine an items eligibility for selection - not the IsEnabled state of its container. So, because the Calendar and its children can accept focus, the ItemsControl considers it eligible for selection.

Thankfully, we can dig ourselves out of this hole by disabling directional navigation on the ComboBoxItems:

<Setter Property="KeyboardNavigation.DirectionalNavigation" Value="None"/>

This has the effect of making the contents of the ComboBoxItem “invisible” to the logic used by the ItemsControl. Therefore, we can no longer select the Calendar with the keyboard.

But the mouse can still be used to select it. At first glance, it looked like I could workaround this by setting IsHitTestVisible to false on the ComboBoxItem and then overriding the coercion logic like I did with the IsEnabled property. However, that didn't seem to work and I'm not entirely sure why. I suspect there are assumptions about hit test visibility in parent/child relationships ingrained into other areas of WPF.

Again, solving this required some inside knowledge into how the mouse clicks were being handled by the ComboBoxItems. Basically, ComboBoxItems pass the various mouse events to the owning ComboBox and the ComboBox decides what to do with them. It's the MouseLeftButtonUp event that causes the item to be selected. Therefore, I added this to the AlwaysEnabledControl:

protected override void OnPreviewMouseLeftButtonUp(MouseButtonEventArgs e)
{
    base.OnPreviewMouseLeftButtonUp(e); 

    //if the user clicks directly on this control, don't let that click propagate to the container
    if (VisualTreeHelper.HitTest(this, e.GetPosition(this)).VisualHit == this)
    {
        e.Handled = true;
    }
}

As you can see, this override ensures any clicks directly on the AlwaysEnabledControl are swallowed. That means the ComboBoxItem will never see the event and therefore the item will not be selected.

There are some other points of interest in the code base, but I'll let you discover them yourself. The end result is that we satisfy all our requirements. And with some minor modifications to the XAML, you can swap the ComboBox out for a different Selector (such as a ListBox).

This technique of having interactive items that are "disabled" from the perspective of the Selector in which they're contained could be useful in quite a few different scenarios. Here are a couple off the top of my head:

A colour pick list that contains the names of many common colours and then an interactive colour wheel at the bottom
A multi-select list of customers (or whatever) with an interactive search item up the top. When the search item is used, it actually resolves to a dynamic query that selects any number of customers based on some criteria

You should note that the attached solution was my POC only. I ended up refactoring the code a fair bit to make it cleaner and more extensible.

Enjoy!

Download the Solution

MAF and MEF

2009-02-24T17:50:00.001Z

Download the Solution

This morning I listened to Glenn Block's MEF talk on Hanselminutes, wherein he touched on the differences between MAF and MEF. I was glad he did. Not only are their names confusingly similar, but their goals seem so on the surface, too.

Glenn sums up the differences well by saying that MEF is about extensibility whilst MAF is about isolation. Moreover, they are not mutually exclusive. It is entirely possible - and legitimate - to use both together.

Indeed, this is something I've been meaning to try and I will cover it in this post. Specifically, I will show how a MAF add-in can use MEF to compose a set of unknown parts to do its job.

First of all, I started with my skeletal MAF solution. I'm really glad I took the time to put that thing together - it has saved me a lot of time with these MAF-related blog posts ;)

Next up, I grabbed the latest preview of MEF from the MEF CodePlex site. I copied the System.ComponentModel.Composition assembly into my skeletal solution and referenced it from my sample add-in. MEF will eventually be part of the framework (version 4.0 is the target) but for now it is standalone.

Then, I defined the interface my add-in will rely on (import):

public interface IMessageProvider
{
    string Message { get; }
}

It will import any implementations of this interface it finds and print out the corresponding messages. I added one implementation of this interface to the add-in project:

[Export(typeof(IMessageProvider))]
public class SampleMessageProvider : IMessageProvider
{
    public string Message
    {
        get { return "A message provider in the same assembly as the add-in."; }
    }
}

I added a Compose() method to the add-in:

private void Compose()
{
    var directory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
    var container = new CompositionContainer(new DirectoryCatalog(directory));
    var batch = new CompositionBatch();
    batch.AddPart(this);
    container.Compose(batch);
}

This method is called by the add-in when it is initialized. It composes the MEF container by looking for all parts in the directory containing the add-in. The easiest way to get that directory was to use the location of the currently executing assembly, since that assembly is the add-in itself.

The add-in imports all message providers:

[Import]
public IEnumerable<IMessageProvider> MessageProviders { get; set; }

And then it iterates over them during its Initialize() method:

public void Initialize(IHost host)
{
    Compose();
    Console.WriteLine("This is the sample add-in, running inside host with name '{0}', version {1}. AppDomain name is '{2}'.", host.Name, host.Version, AppDomain.CurrentDomain.FriendlyName); 

    foreach (var messageProvider in MessageProviders)
    {
        Console.WriteLine(messageProvider.Message);
    }
}

Running the application at this point works just fine and we see the single message provider was found:

Now I wanted to add another message provider in a completely different assembly to the add-in. So I added a new project called MessageProviders. This project references both the System.ComponentModel.Composition assembly as well as the add-in assembly (so it can use the IMessageProvider type). Importantly, the add-in assembly does not reference the MessageProviders assembly. The MEF catalog ties the two together for us. Also, you could imagine that the IMessageProvider interface could be in a standalone assembly, so that the add-in assembly and MessageProviders assembly don't need to reference each other.

I added another message provider to the new project:

[Export(typeof(IMessageProvider))]
public class ExternalMessageProvider : IMessageProvider
{
    public string Message
    {
        get { return "A message provider in an external assembly."; }
    }
}

Then I ensured the build script copied the output of this new project to the add-in's directory. I hit F5 and things just worked:

Both message providers were found by MEF running in the context of a MAF add-in.

To me, one of the benefits of achieving isolation with MAF is that add-in authors are free to use whatever technology they want to meet the needs of their add-in. If they need dependency injection, the host has not imposed on their choice. They can use Unity, StructureMap, autofac, ObjectBuilder or whatever best suits them. And if they need composition, they can use MEF.

Download the Solution

Code Locali[zs]ation

2009-02-05T20:09:00.001Z

Not too long ago I was sitting at my painfully uncomfortable work desk minding my own business when I sensed a presence over my left shoulder. Turning, I discovered one of my managers staring intently at my screen.

"I hope you're going to rename that", he said, pointing at my monitor. He was referring to a method I had named "Synchronize". "We spell that with an 's' here", he stated, perhaps forgetting that Australians share British spelling - or perhaps forgetting that I was Australian.

Assuming that he was joking, I smiled and chuckled. "I'm serious", he said.

And he was.

And I was flummoxed.

Looking through my team's code base I found that they are indeed using the Queen's English in naming their methods and types. I completely disagree with this decision. This post serves as a reference for my reasoning, and as something I can point future colleagues to.

The reason is really simple, actually: consistency. For better or worse, all Windows and .NET APIs are in American English. The last thing I want to see in a code base is this:

public class MyClass
{
    private SomeComponent _component;

    public void Initialise()
    {
        _component.Initialize();
    }
}

Since SomeComponent was developed by those who conform with the status quo, the code has inconsistent spelling. It's inevitable, confusing and sloppy.

We have coding conventions to reduce inconsistencies in code bases. In the interests of said consistency, one of your coding convention should be to use American English. Indeed, I suspect the framework design guidelines state this, but I do not have a copy of the book to confirm.

In saying all this, I can't help but picture my Mum and my high school English teacher - Mr. Butler - standing sternly in front of me, scolding me for my unpatriotic attitude.

Mum, you will always be my "Mum" and never my "Mom", unless you run my software in the US. And if you ever read my code I warn you now that you will see names such as "Initialize", "Synchronize", and "Color". You can scold me only if those spellings surface in the user interface.

Mr. Butler, you practically accused me of cheating in front of my entire year 11 class, so I make no apologies†.

Anyway, my point is that coding in anything other than American English will make your code base inconsistent and harder to maintain. We switch contexts when communicating all the time (think SMS and IM where a whole different lexicon applies), so we should be able to switch context when communicating in code. No biggie, but it makes a big difference to the resultant code.

† Just in case someone takes this too seriously, I will point out that Mr. B was one of the best teachers I ever had. This was a very rare black mark against his name. I had received 98% for my essay on Animal Farm. After congratulating me, he mentioned how similar it was to my sister's effort of two years past, and asked me pointedly whether I had copied it. I hadn't. Indeed, I didn't even know my sister had written an essay on the same topic. I think it far more likely that my sis is a cyborg and she travelled back in time to copy my essay. I will have to ask her about that.

Things I don’t like about Little Big Planet

2008-12-28T22:03:00.001Z

Kentis

2008-12-24T17:24:00.001Z

Download (zip)
Download (exe)

Introduction

Kentis is a Tetris clone that I wrote back in 2004 whilst in hospital awaiting the birth of my daughter. It is packaged as a single executable that you can download from either of the links above.

Kentis attempts to remain true to the original game-play, but with an added arcade feel.

If you have any recommendations for how the game can be improved, or if you are able to provide feedback on whether the game works on any additional platforms, please do so in the comments.

Score System

The scoring system in Kentis favors those who place blocks faster, and eliminate more lines in one move.

The descent speed of blocks can be increased by pressing the down arrow. A block can be dropped immediately by pressing the space key. The faster you drop a block, the greater your score will be for that move. And the greater your current level, the greater your score will be.

For example, suppose it takes you 1 second to place and drop a block. If you’re on level 1, you will score 12 points. If you’re on level 2, you will score 15 points. If you’re on level 9, you will score 27 points.

For each block you place, you will get an additional score if you clear rows with that block. When clearing rows, the score increases exponentially with the number of rows you clear, and linearly with your current level. For example, if you’re on level 1, you will score an extra 46 points for clearing a single row. But if you clear 2 rows in one move, you will score an extra 58 points, and clearing 4 rows will earn you 202 points. Clearing 4 rows whilst on level 9 will earn you a whopping 1010 points – and that’s in addition to your block score.

Options

Kentis includes a number of options that allow you to challenge yourself further as you increase your skill at playing the game. The table below gives a brief description of each option.

Option	Values	Description
Sound	On Off	Turns sound on and off.
Rubbish Rows	0 – 10	Determines the number of rows that will be filled with random “rubbish” at the start of each game. Rubbish is colored gray and can be cleared just like any other block color.
Rubbish Frequency	10% – 90%	Determines how frequent the rubbish will be in the rubbish rows. Rubbish is more challenging if it is sparse and covers many rows.
Starting Level	0 – 9	Determines what level you start each game on.
Block Types	Standard Standard + Extra You’re Crazy!	Determines what blocks you will be playing with. The extra blocks are challenging enough. The crazy setting is just . . . crazy.
Block Preview	On Off	Determines whether you will be given a preview of the upcoming block.
Block Color	Fixed Random	Determines whether block colors are fixed for each type of block, or whether random colors are assigned to each new block.

Requirements

Operating System: Windows XP (98, 2000, and Vista are as yet untested)
RAM: Minimal (tested on 128MB)
HDD: 2MiB
Graphics/Audio: Pretty much anything

Version History

December 2008 : Updated to use resource compression and cut executable size from over 12MiB to under 2MiB.

January 2005 : Original release on gamedev.net.

Kentis Update

2008-12-24T17:18:00.001Z

I’m on leave at the moment and was looking for something a little different to occupy me. To that end, I spent some time over the past couple of days adding resource compression to Kentis. This took the download size from 12.3MiB down to 1.9MiB, so it was certainly worth it!

Kentis used to be hosted on GameDev.net, but in attempting to update my project I found out my membership had expired (no surprise really, given how long it’s been). I was willing to part with a few quid until I saw that their preferred payment method is PayPal, which I hate with the heat of a thousand suns. Therefore, I’ll be hosting it myself, and I’ll provide the details in my next blog post.

For now, however, I just want to discuss the improvements I made.

Image Compression

Previously in Kentis I was using solely bitmaps as my graphic resources. As far as storage efficiency goes, that’s pretty much the worst possible choice. The reason I was using them was for simplicity – I didn’t have to do any conversion in order to consume them in my game because DirectX understands bitmaps directly (I’m using DirectX 7, which does not support JPEGs or PNGs natively).

I have two basic image types in my game: backgrounds and sprites. The backgrounds are large, complex in color, don’t require transparency, and can be stored in a lossy format. The sprites are smaller, have far fewer colors and gradients, do require transparency, and must be stored in a lossless format. JPEG compression is perfectly suited to storing the backgrounds, and PNG is the best candidate for the sprites.

My first foray into providing a solution was to use the ijp libraries. However, I couldn’t even get the simplest of console applications to decode a JPEG without the jpeg_read_header() function throwing an access violation. I never did figure out why, so perhaps I’ll post on stackoverflow later to see if anyone can shed some light.

Anyway, ijp would only be a partial solution because it only supports JPEGs – not PNGs. So I turned my attention to a windows API called StretchDIBits(). This API should allow you to copy a bitmap, JPEG or PNG to a device context (DC). Long story short, I couldn’t get it to work and I’ll come back to my theory why in a minute.

At this point I was getting a little tired of not getting anywhere. I was about to give up and go and watch Band of Brothers on Blu-ray when I happened upon the CxImage library on CodeProject. It looked like a good alternative to the StretchDIBits() API, so I thought I’d give it a whirl. I had to fix some things first though. For one, the projects were not set up with the correct runtime library settings. Secondly, when I tried disabling functionality I didn’t need (such as extra graphic formats, layers, and encoding support) it no longer compiled.

After I got it to compile and link with Kentis, I again ran into problems. I don’t remember the manifestation of the problem, but the point is I spent a good 4 or 5 hours scrutinizing and debugging my code. I eventually tracked down the problem to my .rc file (resource script). Visual Studio had gotten confused somehow when I was making changes to my resources and this file was far from correct. I updated it by hand and recompiled and relinked. Success!

I suspect the problem with the .rc file also prevented the StretchDIBits() API from working. I think I’ll test this theory a little later, because it would be good to reduce the binary size even further. CxImage is a fantastic library, but it has way more functionality than I need. I spent a good amount of time getting it down to a minimum, but getting rid of the dependency altogether may yield even better results.

Anyway, I managed to shave off roughly 4MiB from the executable size by compressing the graphics.

Audio Compression

All the audio in Kentis was stored in WAVE format. Again, this was to avoid any decoding steps but came at the cost of significant storage space. Unlike graphics, all the audio could be encoded in a lossy format.

I settled on Ogg Vorbis as the format. I converted each of my .wav files to .ogg files, incorporated the ogg and vorbis libraries into my code base, and updated parts of game’s audio layer to do the decoding.

It all went rather well. The only hiccup was that the decoding time for the music tracks was excessive (around 2-3 seconds). I tracked down the problem to resizing of a vector<char> I was storing the decoded data in. Even a single resize was costing a lot of time. Therefore, I put in a call to vector::reserve() and an assertion that would let me know if resizing ever occurs in the vector.

Compressing the audio took off a further 6MiB or so off the executable size.

What next?

My goals for these changes were simple: reduce the executable size without affecting functionality at all. I did remove one of the five backgrounds (because the contrast was poor) and two short sounds (because the vorbis libraries didn’t like the sampling rate) but other than that, it is functionally identical to the previous 12.3MiB executable.

I am toying with the idea of doing other updates or doing a different game entirely, but haven’t decided on anything yet.

Visual Studio: Referencing the Same Assembly Multiple Times

2008-11-08T11:43:00.001Z

At work I have the somewhat esoteric requirement of referencing multiple versions of the same assembly from a consuming assembly. The reason why I need to do this is superfluous to this post and I won’t be elaborating on that. It’s the how that is the topic of this post. Regardless of why you need to reference the same assembly multiple times, this post should help you do so if you run into issues.

The first thing you might try is simply adding a reference via Visual Studio’s Add Reference… dialog. However, you’ll get an error if you do this:

A reference to 'C:\Sample\Lib\Example.Model.dll' could not be added. A reference to the component 'Example.Model' already exists in the project.

As highlighted in the error message, Visual Studio uses only the assembly (or project) name to identify references. Therefore, the version of the assembly does not help to disambiguate the reference.

The C# compiler (csc.exe) has a /reference switch to supply references that takes the following format (from MSDN):

/reference:[alias=]filename

Notice that an alias can be optionally supplied. Further down in the MSDN documentation you will read:

Sometimes it is necessary to reference two different versions of the same component from within one assembly. To do this, use the alias suboption on the /reference switch for each file to distinguish between the two files. This alias will be used as a qualifier for the component name, and will resolve to the component in one of the files.

To be clear, the C# compiler does allow us to reference different versions of the same assembly. Those references just need different aliases to disambiguate them.

Cracking open the Visual Studio project file for our consuming assembly, we find something like this:

<Reference Include="Example.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8c3ef16ce2e2f88d, processorArchitecture=MSIL">
    <HintPath>..\Lib\2\Example.Model.dll</HintPath>
    <Private>False</Private>
</Reference>

Thankfully, the Visual Studio limitation can be overcome simply by editing the project file directly. So we can add a reference to version 2 of our assembly with a simple copy, paste and edit:

<Reference Include="Example.Model, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8c3ef16ce2e2f88d, processorArchitecture=MSIL">
    <HintPath>..\Lib\1\Example.Model.dll</HintPath>
    <Private>False</Private>
    <Aliases>legacy2</Aliases> </Reference><Reference Include="Example.Model, Version=3.0.0.0, Culture=neutral, PublicKeyToken=8c3ef16ce2e2f88d, processorArchitecture=MSIL">
    <HintPath>..\Lib\1\Example.Model.dll</HintPath>
    <Private>False</Private>
    <Aliases>legacy3</Aliases> </Reference>

Notice how we’ve added the alias to differentiate the two references in the code. When we load such a project file in Visual Studio, it gives us a warning indicator next to any references it considers to be duplicates:

However, rather than complaining about these at build time, it simply passes the details of these references onto the C# compiler and lets it sort things out:

csc.exe
/reference:legacy2=..\Lib\2\Example.Model.dll
/reference:legacy3=..\Lib\3\Example.Model.dll…

As such, we can consume the referenced assemblies as follows:

extern alias legacy1;
extern alias legacy2;
extern alias legacy3;

namespace ConsumingLibrary
{
    public static class Consumer
    {
        public static void CreateInstances()
        {
            //version 2 of SomeClass
            var v2 = new legacy2::Model.SomeClass();
            v2.SomeProperty = "test";

            //version 3 of SomeClass
            var v3 = new legacy3::Model.SomeClass();
            v3.SomeProperty = "test";
            v3.SomeOtherProperty = "test";
        }
    }
}

The extern alias keyword allows us to pull in the types defined by the assemblies that have been assigned aliases outside of the default “global” alias. Thereafter, we can qualify types with those aliases as per the above example, or even use those aliases to qualify using directives:

using legacy2::Model;

One thing to look out for with all this, is that WPF projects don’t seem to like it. If you add these multiple references to a WPF project the compiler seems to pick one of the references at random and ignores the rest.

Further to this, the only way I could get consistent behavior from the AppDomain.AssemblyResolve event was to separate the consumer into its own library. The entry point to the application attaches a handler to the aforementioned event and then calls into the consuming library to construct the types. Attempting to combine these two activities into the same assembly (even in separate types) would result in the event not always being fired.

Finally, Visual Studio sometimes has trouble providing Intellisense in these scenarios. And sometimes it erroneously places squiggly compile errors where it shouldn’t. Sometimes you just have to ignore them and build.

To see this all in action, you can download the little sample I put together here.

Using ComboBox.Text as a Hint

2008-11-06T19:40:00.001Z

At work I was after a quick-and-dirty way to get a ComboBox to show some hint text like this:

When the user chooses an item, I want to kick off a task but leave the ComboBox exactly as it was (including the hint text). I know there are nicer ways to achieve this by customizing the ComboBox template or by using a different control entirely, but I was integrating this with a third-party ribbon control that precluded any fancy stuff.

The ComboBox control has a Text property that MSDN explains as follows:

When the IsEditable property is true, setting this property places initial text entered in the text box.

My ComboBox is editable to ensure the Text property is displayed, but is read-only to ensure that the user cannot type any text themselves. What MSDN fails to explain is what constitutes “initial”. Is it a one-off thing? Does “initial” mean when there is no selected item?

My first attempt at resetting the ComboBox after a selection was made looked something like this:

_comboBox.SelectionChanged += delegate
{
    if (_comboBox.SelectedIndex == -1)
    {
        return;
    }

    _comboBox.SelectedIndex = -1;
    _comboBox.Text = "Select an Item";
};

Alas, setting the Text property had no effect. The ComboBox would just appear blank after this code executed. Even if I completely reset the ComboBox bindings and properties, it still refused to display the value of the Text property.

I was beginning to think the MSDN documentation was accurate, if a little lacking. It did seem as if the Text property would only be used once prior to the user making a selection. Thereafter, it did not seem to take effect.

On a hunch, I decided to try setting the Text property in a separate message:

_comboBox.SelectionChanged += delegate
{
    if (_comboBox.SelectedIndex == -1)
    {
        return;
    }

    _comboBox.SelectedIndex = -1;
    Dispatcher.BeginInvoke(new ThreadStart(delegate
    {
        _comboBox.Text = "Select an Item";
    }));
};

That did the trick. The ComboBox now correctly displays the Text property after the user selects an item. This seems like something of a bug to me, but I haven’t really investigated further.

You may wonder whether it’s necessary for us to set the SelectedIndex to -1 anymore. It probably isn’t because your hint text is unlikely to match selectable items in the ComboBox. However, if there happens to be a selectable item with the same value as the Text property, setting the Text property will select that item and affect SelectedIndex accordingly. That may or may not be a problem in your scenario. Better to be safe than sorry, I figure…

New Place

2008-11-03T19:53:00.001Z

A couple of weeks ago we moved from Woolwich to North Greenwich, which almost feels like a different country despite being only 30 minutes away. It’s right next to a great park, there’s a shopping center two minutes down the road, and the bus stops on our doorstep to take me on my 15 minute commute to work. Oh, and people are actually nice in this neighborhood.

Since the move I’ve been wrestling baffling feats of BT incompetence to get my Internet connection back. Seriously, it was like being stuck in the middle of a scene from Idiocracy. The highlight was when a BT operator asked me to urgently call another BT number to correct one of their many mistakes.

Despite the odds, I’m finally back online and have a bunch of catching up to do. Things aren’t entirely fixed yet (faulty wireless on their “new and improved” router, and extension points in my house aren’t working) but I’ve managed to cobble together something from the bits and bobs of my old router and the master point tucked away in one of the cupboards in our house.

I have a couple of posts written and saved up during the down-time. Given that a “stay tuned” post is a blogging sin and all, let me give this post some more substance with some photos of our new abode, courtesy of our budding photographer, Tempany:

(the neighbours)

(decor)

(Boris the bear on Tempany’s bed)

And here are some we took:

(Modern dishwashers: cute, but unreliable)

(a very sick Tempany, unrelated to previous photo)

(all better now, out seeing Disney’s Nemo on Ice)

Customizing Logical Children

2008-10-04T17:05:00.001+01:00

WPF’s logical tree is used in providing all kinds of functionality, such as property inheritance and resource resolution.

Yesterday a colleague asked me how to customize the logical children of a control. Basically, he had a control that hosted a collection of child items that aren’t actually visuals. In the XAML, he wanted to be able to bind properties of the children. Kind of like how you can bind to the Height property of a RowDefinition in a WPF Grid control. The RowDefinition isn’t a Visual, but it can participate in binding by virtue of being part of the logical tree.

My initial thought was to override the FrameworkElement.LogicalChildren property, but he had already tried that without success. Altering the logical tree is not something I’ve ever had need to do before. Therefore, I decided to try this out for myself and am recording my findings here.

To test this all out, I created a user control called ArtistsControl that has an Artists property containing a collection of Artist objects. Each Artist object just has a name. The ArtistsControl contains a ListBox that shows each Artist in the collection.

I wanted to address the following use cases:

Non-bound Artist declaration
Artist bound to a property on the owning Window
Artist bound to a property on the current DataContext
Artist whose name comes from a statically-resolved resource defined in the owning Window
Artist whose name comes from a dynamically-resolved resource defined in the owning Window
Artist bound to a property on the owning Window, but done in the code-behind setting the source of the binding directly

Aside: The first issue I came up against had nothing to do with the initial problem at all. I wanted to define a user control called ArtistsControl that had a collection property called Artists that could be populated very easily from XAML:
<local:ArtistsControl>
    <local:Artist>Powderfinger</local:Artist>
</local:ArtistsControl>
However, I kept running into obscure compile errors such as:

Cannot set content property 'Artists' on element 'ArtistsControl'. 'Artists' has incorrect access level or its assembly does not allow access.

Long story short, the problem was that my dependency property was of type IList<Artist>. In order for the collection to play nice with XAML, it needs to be a non-generic type (can’t even be a closed generic type). To resolve this I just created my own ArtistCollection type which inherits from ObservableCollection<Artist>. After that, the above XAML snippet worked fine.

#1, #4 and #6 all work fine “out-of-the-box”. That makes sense because they don’t rely on the logical tree in any way.

As I mentioned earlier, the first thing I tried at this point is to override the LogicalTree property in ArtistsControl:

protected override IEnumerator LogicalChildren
{
    get
    {
        if (Artists == null)
        {
            yield break;
        }

        foreach (var artist in Artists)
        {
            yield return artist;
        }
    }
}

This has the effect of fixing . . . nothing!

However, I did notice this error in the output window:

Cannot find governing FrameworkElement or FrameworkContentElement for target element.

This led me to change the base class of Artist from DependencyObject to FrameworkElement. This also did nothing to solve the other use cases. But it did change the error in the output window to:

Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='System.Windows.Window', AncestorLevel='1''. BindingExpression:Path=Tag; DataItem=null; target element is 'Artist' (Name=''); target property is 'ArtistName' (type 'String')

Hmmm. I have supposedly made the Artist objects part of the logical tree, so why can they not resolve anything further up the tree?

I had an epiphany around this point when I realized:

Just because the parent acknowledges the child, that doesn’t mean the child acknowledges the parent.

In other words, just because the Artist objects are part of the ArtistControl’s LogicalChildren collection, that doesn’t mean the Artist objects have their Parent property set to the ArtistControl. The logical tree is a two-way connection: the child is connected to the parent, and the parent is connected to the child.

So how do we connect the two? FrameworkElement.Parent is a get-only property, and WPF uses internal methods to alter its value. Fortunately FrameworkElement defines a couple of methods to help us here: AddLogicalChild() and RemoveLogicalChild(). All we need to do is call these methods to add and remove Artist objects to and from the logical tree.

Overriding the LogicalChildren property allows property inheritance to work. The attached sample will still work without it, but any inherited properties will fail to propagate within your custom logical tree unless you also override LogicalChildren.

When all is said and done, all use cases are satisfied and the following XAML works fine:

<local:ArtistsControl ...>
    <local:Artist>The Smashing Pumpkins</local:Artist>
    <local:Artist ArtistName="{Binding Tag, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}}"/>
    <local:Artist ArtistName="{Binding Tag}"/>
    <local:Artist ArtistName="{StaticResource StaticArtistResource}"/>
    <local:Artist ArtistName="{DynamicResource DynamicArtistResource}"/>
</local:ArtistsControl>

Download Sample

Installing Trac Explorer

2008-09-10T20:10:00.001+01:00

Couldn’t find an existing post on this, so I’ll post here with the hope that it will be of some help to others.

I was playing around with Trac Explorer (previously known as VSTrac) today, which is a Visual Studio add-in that provides Trac integration. My initial impression is that it’s pretty cool and if you use Trac in conjunction with Visual Studio I’d recommend checking it out.

Anyway, I carefully followed the installation guide, only to find that the Trac Explorer menu item did not appear in my View menu as it should. Turns out that the suggested installation path is not included by default as an add-in folder in Visual Studio. It’s easy to add any path though.

Click on Tools/Options and select the Add-in/Macro Security tree item:

Then click the Add… button to add the path that contains the Trac Explorer add-in. Restart Visual Studio and you’re done.

Incidentally, the %VSMYDOCUMENTS%\Addins entry looks promising, but the VSMYDOCUMENTS environment variable is undefined in both my VS2008 installations. Odd – perhaps this is a regression issue with VS.

Building VSTO Projects without Visual Studio

2008-08-25T16:26:00.001+01:00

At work, I recently added a VSTO project to our solution. Predictably, the build server didn’t like it. Less predictably, I found that the installation package required to build VSTO projects also required Visual Studio to be installed:

My initial thought was that there must be another installer that does not require VS to be installed. However, after searching high and low I couldn’t find such a beast. I had an MS employee confirm this rather unsavory situation here.

Frankly, this blows, since it wastes a VS license and also causes a VS instance to spin up on every build (which is very often when you’re doing CI with multiple projects hosted on the same build server). It just makes CI far messier and costly to set up and run, which is exactly the kind of friction I’d very much prefer to avoid.

And when you think about it, it’s completely unnecessary. What is VSTO besides some combination of managed and unmanaged DLLs? Why on earth is VS required to build a VSTO project? Next you’ll tell me I need Office installed on the build server!

Thankfully, it’s not required (except by the installer), and this post details how you can set up your build server to build VSTO projects without the overhead of VS. There may be simpler ways (by tricking the installer, for example), but this is how I achieved it.

To write this post I set up a clean VPC with XP installed. I then created a VSTO project (Excel 2007 add-in) on the host machine and documented the steps necessary to build it on the guest machine. Some of these steps may not be necessary on your build machine (the first two steps in particular) but I’ve listed them here for completeness.

1. Install the .NET Framework. I used .NET 3.5 Framework for the purposes of this post.

2. Install the .NET SDK. For this post, I used the Windows SDK for 3.5 and only installed the .NET developer tools component.

Attempting to build at this point obviously yields an error:

C:\TestAddIn>msbuild TestAddIn.csproj
Microsoft (R) Build Engine Version 2.0.50727.1433
[Microsoft .NET Framework, Version 2.0.50727.1433]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

C:\TestAddIn\TestAddIn.csproj(180,11): error MSB4019: The imported project
"C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.Office2007.target
s" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

3. Copy the folder C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\OfficeTools from a developer machine that can build the VSTO project to the same location on the build server.

Now attempting to build gives us a different set of errors along the lines of:

ThisAddIn.cs(3,17): error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft'
(are you missing an assembly reference?)
ThisAddIn.Designer.cs(19,55): error CS0234: The type or namespace name 'Office' does not exist in the namespace 'Microso
ft' (are you missing an assembly reference?)

I think we can answer the question of ‘are you missing an assembly reference?’ with a resounding ‘yes!’. There are obviously a whole bunch of VSTO-related assemblies present on the developer machine that are not yet present on the build server. So how do we get them there?

We have a couple of choices. One, we could manually copy VSTO assemblies from the developer’s GAC to the build server’s GAC. Two, we could change the project such that it references a copy of the VSTO assemblies rather than referencing them in the GAC. I opted for the latter approach, because it is more self-contained.

4. Place a copy of the VSTO assemblies into a Lib (or similar) directory for your project. Reference these copies rather than those in the GAC. The easiest way to do this is to change the Copy Local property to true on the existing references, rebuild, copy the assemblies from the build output directory to the Lib directory, delete the old references, and then re-add the references by using the copies in Lib.

Now we get:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.Office2007.targets(
146,9): error MSB4062: The "VerifyClickOnceSigningSettings" task could not be loaded from the assembly Microsoft.VisualS
tudio.Tools.Applications.BuildTasks, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load f
ile or assembly 'Microsoft.VisualStudio.Tools.Applications.BuildTasks, Version=9.0.0.0, Culture=neutral, PublicKeyToken=
b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> de
claration is correct, and that the assembly and all its dependencies are available.

Fair enough. VSTO has some custom MSBuild tasks that the .targets file refers to, but is unable to load. If we crack open the .targets file we see declarations such as:

Since AssemblyName is specified (and not AssemblyFile), a probe for the assembly is occurring same as it would for an Assembly.Load() call. To rectify the situation, we need to . . .

5. Copy the Microsoft.VisualStudio.Tools.Applications.BuildTasks assembly from the developer machine to the build machine and register it in the GAC with gacutil.exe.

6. Do the same for Microsoft.VisualStudio.Tools.Office.BuildTasks.

We’re getting close now, but there are still some missing assemblies. We could manually GAC them as per step #6, but it turns out all the remaining assemblies are part of the VSTO runtime. Therefore, we can just install the runtime.

7. Install the VSTO runtime on the build server. Since I’m using Office 2007 in this post, I used the VSTO 3 runtime. See this page for information on which runtime you require.

8. Build!

Yay! Similar steps can be followed for Office 2003 projects (which is what we’re using at work, actually).

Belfast

2008-08-25T11:11:00.001+01:00

The first thing that struck me about Belfast was how incredibly neat, consistent, and well laid out it looked from above. The city itself did not disappoint – it was very clean and pretty.

The night of our arrival we walked around the city center, took a trip on their wheel (like a smaller version of the London Eye), and did some shopping.

The next day we visited the Belfast zoo, which is situated not too far from the airport. The weather didn’t hold out for us, but we got to see a lot before the downpour.

After that, we got to check out Carrickfergus Castle, albeit briefly and from the comfort of a dry car.

We also met some of Belinda’s relatives for the first time whilst in Belfast – all very nice people. I won’t post their photos of course, but if you’re a family member give me a shout and I’d be happy to send them through.

London Underground WPF Demo

2008-08-09T00:46:00.001+01:00

A while back I did an internal presentation for Infusion on WPF – a short crash course to get people interested and familiar with the basics. For it, I wrote a couple of WPF applications, each of which addressed the same use case with a very different interface. The use case was simple enough:

Allow the user to select two London train stations and show shortest route between those stations.

I had grand plans to turn this into a much larger demo based on Composite WPF (Prism), but unfortunately have never had the time. Instead, I’m just going to post about it here in case anyone is interested in taking a look. First, I’ll briefly describe each of the projects in the solution.

Demo.Domain

This project contains a very simple domain layer as shown below:

Any one station exists at a single coordinate and can have any number of lines running through it. It can connect with any number of other stations via a given line. A trip represents a hop from one station to another via a line. That’s pretty much it.

Demo.Service

This project defines a couple of services that are used by the UI layer.

The first service is the data service, which contains all the reference data describing the stations and their connections etcetera.

The second service – the route service – provides an interface by which callers can determine the shortest route between any two stations. The definition of “shortest” is left up to the specific service implementation. For the purposes of the demo, I wrote a single implementation based on Dijkstra’s algorithm which used the geographical distance between stations as the edge path cost. In other words, this service will tell you how to get from station A to station B whilst covering the shortest possible distance.

There’s also a simple service manager in this project, in lieu of anything more sophisticated (which may have been a distraction).

Demo.DataSuck

This project is just a helper tool. You don’t actually need to run it to see the demo. It takes the XML data file used by the data service and automates Google Earth to locate each station and record its coordinates. It saved me a lot of time because all I needed to do was fill in the Input.xml file and it would spit out the Data.xml file used in the service layer, complete with accurate coordinates.

During the presentation, I actually wrote this project whilst explaining what I was doing. It’s a simple UI that allows the user to pick stations from two lists. They can then click on a button and the shortest route is displayed in a third list:

It’s far from perfect, but it demonstrated a number of core WPF concepts such as layout, data binding, commands, and data templating.

Demo.UI.Controls

This project contains a bunch of controls that are used by the second take on the UI (discussed below). Specifically, there’s a legend (which, for some inexplicable reason, I called “GraphLegend”), a control for showing directions, and a control showing a map.

Demo.Take2

This stupidly-named project is a second take on the UI that shows a more advanced, WPF-like approach to solving the use case. It uses the geographical information available for each station to position them in 2D space. It draws appropriately-colored lines between stations to represent the train lines. It supports zooming and panning. And the user can simply click on stations to see the shortest route between them, both graphically (see the green highlight) and textually.

It looks something like this:

Like I said, I had grand plans for this, including putting satellite imagery in the background and making the lines more true to form, but you know how it is ;)

Below, you can download the code as well as a few PowerPoint slides I put together for the presentation. Enjoy!

Download PowerPoint Deck
Download Source Code

WPF: Disabling Menu Items with Feedback

2008-08-05T09:27:00.001+01:00

I was listening to episode 14 of StackOverflow on the way to work, wherein Joel and Jeff discuss disabling menu items:

[JOEL] …don't disable menu items that aren't available. Uh, instead, leave them enabled, and that gives you an opportunity to tell people why that particular item was not gonna work.

Further on in the conversation:

[JOEL] there's obviously a great middle ground here, where you try to disable the menu item somehow, but you still provide some indication as to what would have to be done to enable it, or why it doesn't work.

WPF lets you do this quite easily:

<MenuItem Header="StackOverflow" IsEnabled="False" ToolTip="You don't know C." ToolTipService.ShowOnDisabled="True"/>

Obviously you would actually bind the ToolTip property so that it varies depending on the IsEnabled state of the MenuItem. The end result is:

PS. Too short? ;)

ItemsControl as Basis for Pie Chart

2008-07-29T10:55:00.001+01:00

From this excellent article:

If someone out there can demonstrate how to modify an ItemsControl so that the items it contains are rendered around a circle to produce a pie chart, I would love to hear from them

That’s what I’m going to do in this post.

The key is to change the ItemsControl’s ItemsPanel to something that allows explicit positioning of child items. Normally I would use a Canvas, but Colin’s PiePiece shapes have their own positioning logic so I used a Grid instead:

<ItemsControl ItemsSource="{Binding DataPoints, ElementName=_root}">
    <ItemsControl.ItemsPanel>
        <ItemsPanelTemplate>
            <Grid/>
        </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>

Then I used a few multi-converters to calculate the WedgeAngle, RotationAngle and Fill of each PiePiece:

<ItemsControl.ItemTemplate>
    <DataTemplate>
        <b:PiePiece Radius="100" CentreX="200" CentreY="200">
            <b:PiePiece.WedgeAngle>
                <MultiBinding Converter="{StaticResource WedgeAngleConverter}">
                    <Binding RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="ItemsSource" RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="."/>
                </MultiBinding>
            </b:PiePiece.WedgeAngle>
            <b:PiePiece.RotationAngle>
                <MultiBinding Converter="{StaticResource RotationAngleConverter}">
                    <Binding RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="ItemsSource" RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="."/>
                </MultiBinding>
            </b:PiePiece.RotationAngle>
            <b:PiePiece.Fill>
                <MultiBinding Converter="{StaticResource FillConverter}">
                    <Binding RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="ItemsSource" RelativeSource="{RelativeSource FindAncestor, AncestorType={x:Type ItemsControl}}"/>
                    <Binding Path="."/>
                </MultiBinding>
            </b:PiePiece.Fill>
        </b:PiePiece>
    </DataTemplate>
</ItemsControl.ItemTemplate>

Each converter is pretty straightforward, and the FillConverter is very dumb indeed because it will run out of colors and throw an exception if there are too many data points (this is, after all, just a quick and dirty example of how to achieve the stated goal). The RotationAngle converter is the most complex:

public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
    var itemsControl = values[0] as ItemsControl;
    var dataPoints = values[1] as ICollection<double>;
    var dataPoint = (double)values[2];
    var dataPointIndex = itemsControl.ItemContainerGenerator.IndexFromContainer(itemsControl.ItemContainerGenerator.ContainerFromItem(dataPoint));
    var total = dataPoints.Aggregate((working, current) => working += current);
    var totalToCurrentDataPoint = 0d;

    if (dataPointIndex > 0)
    {
        totalToCurrentDataPoint = dataPoints.TakeWhile((value, index) => index < dataPointIndex).Aggregate((working, current) => working += current);
    }

    return (totalToCurrentDataPoint / total) * 360d;
}

It figures out the index of the current item by using the ItemsControl’s ItemContainerGenerator. Note that this code is fragile because the data points are of type double. As such, if any two data points have the same value, this code will incorrectly determine the index and the pie chart won’t look right. An easy way to work around this is to use a reference type for the data points.

Once it knows the index of the item, it can work out how the total of data prior to the item, and the total of data in the whole data set. Based on that, it can work out the rotation angle.

The end result looks like this:

Anyway, this was just a quick answer to Colin’s question. I will post a comment on his article pointing back to this post.

You can download my code here.

Paris

2008-07-22T16:01:00.001+01:00

Dirty. Expensive. Confusing. Those are words I would use to describe Paris.

Perhaps we were unlucky, but the neighborhood we stayed in (north-east of the city, near Gare du Nord station) was far from idyllic. The streets were paved in rubbish and dog crap, and we witnessed plenty of Parisians adding their own bodily fluids into the soup. Charming.

Eating out was nice enough, but really took its toll on the wallet. One place charged us €6.50 per beer! Of course, they didn’t tell us that until we’d finished drinking. And when we questioned the price, the manager was at the ready with a menu in hand. I suspect it was the specially-printed “tourist” menu.

As for getting around, it wasn’t too bad but was quite frustrating at times due to the strange layout of the city and the lack of good signs. There’s appears to be nothing consistent or logical about the geometry of the streets. It’s really kind of random.

It’s not all bad though. Central Paris was amazing. Notre Dame and The Louvre were a sight to behold (apart from the eyesore that is The Louvre Pyramid). The Eiffel Tower also looked great, but we didn’t get up close.

The second day saw us at Disneyland where rides and signatures are free, assuming your time and energy are worthless. Seriously – well over an hour to get Cinderella’s signature. By the time I reached her, she had changed shift and I got Snow White instead. I was heartbroken ;)

Tempany loved it all, though, which is the important thing.

The next day we went shopping. We were told to check out a local shopping center, and check it out we did. It was pretty good, and I picked up some shirts (€35 each, in case you were wondering). However, I was disappointed not to see more Asterix and Obelix merchandise.

The final day was a write-off, as we pretty much just hung around waiting for our train. Incidentally, Eurostar was great. Far less hassle than flying, and the difference in travel time is negligible.

I’ll probably go to France again one day, if only to see the Asterix and Obelix theme park.

Hawkeye

2008-06-30T14:38:00.001+01:00

Finally, it looks as though Hawkeye will be outed. It was always telling to me that suddenly we weren’t shown video replays of close calls anymore, only the Hawkeye simulation. I suspect if we were shown side-by-side replays all along then the technology would have proved to be inaccurate to the general public a lot sooner. Of course, it’s probably still more accurate than the human eye.

On the subject of tennis, we went down to Wimbledon last Friday. There was a nice five hour wait to get into general admission. Five hours in line with a three year old to see maybe the last hour’s play? Sure!

MAF Gymnastics: Service Provider

2008-06-18T09:32:00.001+01:00

Download the Solution

If you’ve ever worked on a composite application, you’ll know that services are their backbone. Services allow modules in the application to collaborate in both state and behavior. Moreover, services can be swapped out easily, since the modules work against an interface and are (hopefully) ignorant of the implementation behind the interface.

This post will address how to implement a service ecosystem using MAF in a composite application. In particular, how we can do this whilst keeping the host agnostic of the services it is hosting, and providing version tolerance for the services. Whilst I focus on composite applications, the techniques here can also be applied in non-composite applications.

Requirements

Agnostic Host

One of the challenges of implementing a service provider in MAF is ensuring that the host is capable of hosting any service, not just those services it knows about at compile-time. Without this ability, it’s not really a composite application and does not permit the kind of collaboration between add-ins that such an application requires.

Of course, the types related to the services must not be loaded into the host’s AppDomain. The services need to be isolated just like any other add-in.

Version Tolerance

Consider how composite applications are often written in the real world. You have a bunch of autonomous teams, each team producing and/or consuming services. Some teams consume services provided by other teams.

Then there’s the shell (aka “host”), which is responsible for hosting these modules and allowing them to collaborate. The shell is often produced by another team altogether to those producing the modules (aka “add-ins”).

Now think about what happens when one of the service-providing teams decides they need to modify their service interface. They can potentially break all the modules that depend on that service. In other words, the consumers of that service are at the mercy of the service provider.

MAF pipelines already provide a nice solution to this problem between the host and add-ins, but wouldn’t it be nice if the service provider could version their service over time, providing backwards compatibility as desired?

Solution

Add-in Types

The contracts define two types of add-ins: an application add-in and a service add-in.

At this point, the difference between a service add-in and an application add-in is minimal. A service add-in provides an ID by which it will be resolved by consuming add-ins.

Both add-in contracts have a common base interface (IAddInContract) from which they inherit an Initialize() method. Notice how this method returns an instance of AddInInitResult. This is crucial to the host being able to track which add-ins are hosted in which AppDomains.

The add-in views do not have this added complexity:

This is good, because the add-in developer need not worry about returning anything from their Initialize() implementation. Instead, this is handled by the adapters, as we’ll see later.

The host views mirror the contracts very closely, since the host does need to know and track this extra initialization information:

Add-in Activation and Tracking

When the host starts up, it first finds and activates service add-ins and then application add-ins. In both cases, it remembers the contract object for the add-in (that is, the MarshalByRefObject implementing the add-in). For services, it also maps the service ID back to the AddInToken so that it can obtain the contract implementation given only the service ID. This is important, of course, and you’ll see why soon.

Note that the tracking information is only actually necessary to support services, but the host code tracks application add-ins too, since that made the logic simpler.

The Host

It’s time to look at the pipeline components for the host. Firstly, the contract:

We’re getting closer and closer to the nitty-gritty now (I can’t believe that’s in the dictionary). The host contract has two methods of importance on it: GetPipelineDetails() and GetServiceDetails().

The former is quite simple: it just retrieves some basic information about the MAF pipeline. This information is needed by the add-in side adapters to support services. We’ll look at this further below.

The latter is also straightforward: it retrieves the service contract for a given service ID. Recall from above that when we activate services we track some information about that service. This method just allows the caller to retrieve that information.

The host view of the host is a mirror of the contract, so I won’t bother talking about it here. The add-in view of the host, on the other hand, is quite different:

As you can see, add-ins get a simpler view of the host. There is a single method that they can use to resolve a service by ID. There is no nonsense about getting pipeline information or what have you. The service consumer doesn’t care about that - she just wants a service.

I made this method generic just to save a little casting in the add-ins, but in reality I haven’t decided how I’d best like to compose this interface. I’m considering having the ID automatically determined by the interface type the service implements, so add-ins don’t even need to provide an ID. However, I haven’t spiked this yet so I don’t know if it will play out exactly as I hope. Anyway, I’ll be looking at that soon for a real project.

UPDATE: It works great! In my “real” project services do not need to explicitly provide an ID. Instead, the adapters infer it based on the view type the service implements. In addition, services are not explicitly requested from the host. Instead, the adapters determine the services an add-in requires by examining its Initialize() method and injecting any dependent services automatically. This results in a really nice, low-friction add-in development experience.

The Adapters

Based on the interfaces we just saw, you might assume that there’s some magic happening in the adapters to close the gap, so to speak. And you’d be right.

What we need to do is connect up the service consumer add-in to the service add-in, which already exists in its own AppDomain. Indeed, we may need to connect up multiple consumers to the service. Those consumers might be application add-ins or even other service add-ins (the sample only demonstrates the former, but the latter should work too assuming that the services are activated in the correct order).

Consider the following diagram:

The black lines represent the “primary” pipeline between the host and the add-ins, be they regular application add-ins or service add-ins. In the diagram we have a single service add-in (up the top) and two consumers of that service. The two consumers are built against different versions of the service (V1 and V2) but they both need to consume whatever version of the service is loaded (assuming the appropriate pipeline adapters can be found).

The service’s interface (ISomeService) extends the core service interface provided by the host (IService). Actually, this extension occurs in both the contracts and the views. As such, the service pipeline components depend on the pipeline components provided by the host. For the purposes of the primary pipeline, only the implementation of IService is used (that is, IServiceContract is used for communication over the black pipelines).

The blue lines represent the “secondary” pipeline between the service consumers and the service. It is this pipeline that provides marshalling specific to the service implementation (ISomeService).

And it is here where we need to employ some trickery to get the job done. First though, thanks to the anonymous commenter who pointed out an easier way to do this.

Here’s how it works. The add-in side contract to view adapter for the IHost interface implements the ResolveService<T>() method we saw above. In order to do this, it needs to construct a pipeline between the caller (ie. the consuming add-in) and the service itself.

The host’s AppDomain is impartial to this whole process – it merely provides some information the adapter needs to set up the pipeline. Once the adapter has this information, it uses MAF’s ContractAdapter type to adapt between the add-in’s view of the service and the existing service instance (ie. create the pipeline represented by the blue lines above). Specifically, the ContractToViewAdapter() method is used because we’re taking an existing contract (the service instance) and adapting it to the view.

Since the ContractToViewAdapter() method is generic and we don’t know the type until runtime, we need to invoke it reflectively. It might be nicer if MAF included non-generic overloads for these methods, but the fact that they’re public means that we do not need elevated privileges to invoke them via reflection. Thus, your add-in can still be hosted in a low-trust AppDomain.

Of course, once this pipeline is constructed we don’t need to do so again for the current AppDomain (unless a different view of the same service is used from within the same AppDomain, and the code caters for that case too). Therefore, we cache this information. Subsequent calls to ResolveService<T>() won’t even leave the caller’s AppDomain, which I think is pretty cool. Of course, calling into the service itself will marshal to the service’s AppDomain as expected.

Limitations

There are a couple of things you need to be aware of with respect to this technique. First and foremost, I mentioned above that MAF can only deal with one pipeline at a time. Further to this, it can only resolve one assembly from each pipeline folder. For example, all your add-in side adapters need to be in a single assembly inside the [Pipeline]\AddInSideAdapters folder. If your add-in side adapters assembly depends on another assembly, that assembly must be in the GAC in order for MAF to resolve it. MAF will not try to resolve that assembly from the same pipeline directory from which your add-in side adapters were loaded.

The problem with this is that the service pipelines depend on the host pipeline. As a simple example of this, the ISomeServiceContract included in the download extends the host’s IServiceContract. The upshot is that the host’s pipeline must be in the GAC.

In fact, this GAC registration requirement spreads virally throughout your pipeline projects. If you look in the sample you’ll see that most pipeline assemblies are registered in the GAC when you build. As such, you’ll need local admin since gacutil requires this. Unfortunately, I don’t see a way around this given MAF’s current architecture.

It’s important to point out that installing the pipeline components in the GAC is almost certainly what you want to do for deployments. Otherwise these assemblies cannot be shared between AppDomains and performance suffers badly. It’s just a shame that it’s also required for development.

Related to this issue is the possibility of name clashes in pipeline assemblies. You may have many teams working on services, and the pipeline assemblies for those services must reside in the same folder. Therefore, if one team chooses the same assembly name as another you will get a clash. This is pretty unlikely, but it’s something to keep in mind.

Less a limitation and more a “gotcha”: notice how the service implementation (in the Service project) references the service add-in views project (Service.AddInViews) and the service consumer add-ins reference the service host views project (Service.HostViews). In MAF terminology, the consumers are “hosts” of the service. This terminology doesn’t quite fit here because the consumers aren’t explicitly activating the service. In a real application, I would probably rename the service add-in views and host views to “provider views” and “consumer views” accordingly.

The Result

If you download and execute the sample you’ll see this:

As unexciting as this looks at first glance, it’s actually really, really cool. Trust me. What we’re seeing here is that there are four AppDomains:

One for the host
One for the service
One for the first service consumer
One for the second service consumer

The host and its pipeline know nothing about the specific service at compile-time. That is, it has no knowledge of ISomeService, only IService. And yet, it is hosting this service. That’s a check for an agnostic host.

The first service consumer is executing against version 2 of the service. It sets a value on the service to 26 and outputs the results of calling the service’s GetTimestamp() method. When it calls this method, it passes in a custom format string of “ddd MMM yyyy”.

The second service consumer is executing against version 1 of the service. It gets the value of 26 set by the first consumer and outputs it. Then it calls the service’s GetTimestamp() method and outputs that. But what’s cool is that version 1 of the service did not allow a custom format string to be passed into this method! The adapters for the service (see the Service.HostSideAdapters_V1toV2 project) are automatically using a default format string of “dd/MM/yyyy”. This proves that the correct pipeline components have been selected and used to join the service consumers to the service – that’s a check for version tolerance.

We have achieved everything we set out to achieve here. The host is agnostic of the services it will be hosting at runtime and none of the service types leak into the host. Moreover, the pipeline between service consumers and the service itself has all the intelligence you’d expect of a MAF pipeline. It selects the correct components to ensure that the service consumer can interact with the service, even if the consumer was built against an older version of the service.

Conclusion

Composite applications need a facility to provide and share services. An effective shell for a composite application needs to be agnostic of the services it is hosting, otherwise developers leveraging the shell are hamstrung by its intrinsic assumptions about the services it will host.

MAF’s concept of pipelines to handle version tolerance are equally applicable to services as they are to the shell itself. That’s simply because of the relationship between the provider of the deliverables and its consumers. As a shell or service developer, there is some uncertainty as to how many teams are leveraging your work, and how long they need to migrate to newer versions of your deliverables. Pipelines allow you to provide backwards compatibility so that consumers are not forced to update their code bases straight away.

The solution presented in this post solves both these problems. The shell knows nothing about the exact services it will be hosting at runtime. In addition, it uses a pipeline provided by the service developer to connect the service consumers to the service.

This was a particularly difficult topic to articulate, and I’m not confident that I did so well. If I failed to convey this information adequately, feel free to let me know in the comments and I’ll do my best to rectify the situation.

Download the Solution

MAF Gymnastics: Event Hub

2008-06-11T21:40:00.001+01:00

Download the Solution

The first problem I will attempt to address in this series is that of providing an event aggregator service (which I call an event hub, just to save on typing). That is, how can we allow add-ins to subscribe to, and publish events on a many-to-many event bus that is managed and implemented by the host?

When using MAF, there are a number of problems that must be solved in order to facilitate such a service. For one, how can we present a decent API to the add-in developer? The lack of generics support in MAF makes this difficult (see my previous post for details), and limits the overall effectiveness of the solution.

Next up, how can we ensure that event subject types (the CLR types that contain event payloads) do not leak into the host? If two add-ins communicate with a custom subject type, that type should not be loaded into the host's AppDomain. It should only be loaded into the AppDomain of those add-ins that care about that particular event.

With that in mind, how can we allow the host to use the event hub in much the same way as add-ins? That is, how can we design the host views such that the host can remain agnostic of subject types where necessary, but can publish and subscribe on the event hub where desired?

Finally, we'll discuss how the event hub service is exposed to add-ins. That is, how does an add-in actually obtain an instance of the event hub service.

The API

The contracts for the event hub service looks like this:

Importantly, you can see that there is nothing in these APIs that will cause types to leak from the add-in AppDomains to the host (or vice-versa). A string is used to identify subjects as opposed to a CLR type or RuntimeTypeHandle, both of which will result in errors because the corresponding subject type may not be available to the host. Also, subjects themselves are passed around as a byte array rather than an object instance. That allows the host to remain completely unaware of the actual CLR types involved.

The views for the event hub service look slightly different depending on whether you're an add-in or the host. For an add-in, the API looks like this:

The ISubscriber interface is what event subscribers must implement. It has a single method that is called when a relevant event is published on the event bus. The IEventHubService interface allows events to be published, and subscribers to be registered and unregistered.

A CLR type is used to scope events. That is, subscribers register their interest in events with a certain subject type. Subscribers will only receive events of types they have registered their interest in. In reality, you might want add-ins to just use a string to identify events. However, I wanted something that demonstrates how to differ your view from your contract.

This API is fairly clean and simple, but suffers from a lack of generics. Ideally, we would be able to define a generic ISubscriber<T> interface and have subscribers receive a strongly-typed subject argument. However, whilst the MAF pipeline does allow generic members in non-generic types, it does not allow generic types. That's because it must automatically hook up contracts and views with their corresponding adapters. If the contract or view is a generic type, MAF is not able to close the type (presumably because it does not have enough information to do so).

The API for the host is a little more complicated than that for the add-in:

The reason for the complication is that we want the event hub to be usable from the host in much the same way as it is from an add-in. To that end, we differentiate between two different subscribers: add-in subscribers and the host itself. There are basically two "modes" that the host-side works in: type-agnostic (add-in subscriber) and type-aware (host subscriber). The type-aware mode is not strictly necessary for the host to work with the event hub, but it sure makes it easier and consistent with the way the event hub works for add-ins.

The finally part of the API I want to draw your attention to is the IHost interface:

The EventHubService property on this interface is the means by which add-ins actually gain access to the service. In a later post I will discuss a more generalized and extensible way of exposing services to add-ins.

Adapters

The key to this solution is contained within the adapters. The adapters ensure that the host remains blissfully unaware of subject types and payloads. Consider this add-in code:

host.EventHubService.Publish(new CustomEventSubject() { Message = "Giggidy giggidy!" });

The add-in side view-to-contract adapter adapts this call such that the subject type (CustomEventSubject) is converted to a string used to identify the event, and the subject itself (the CustomEventSubject instance) becomes a byte array via standard .NET serialization. Neither parameter makes it unscathed into the host's AppDomain, which is fortunate because that would cause problems where the subject type was unknown to the host. The contract-to-view adapter does the opposite: it resolves a .NET Type instance based on the identifying string, and deserializes the byte array into an instance of the subject type.

If little alarm bells are going off inside your head right now after hearing about the automatic (de)serialization, it’s for good reason. I discuss why you should use the event hub service with care below.

Host

The host is largely untouched with respect to the skeletal solution. The one change is the use of qualification data to dictate the load order for add-ins. We need the subscriber add-in to load prior to the publisher add-in, otherwise the event publication will occur before there is a subscriber!

Each add-in has a QualificationDataAttribute applied to it to specify the load order. The host then uses the value in this attribute to order the add-ins prior to activation:

var orderedTokens = from token in tokens
                    orderby int.Parse(token.QualificationData[AddInSegmentType.AddIn]["LoadOrder"])
                    select token;

Note that this is just a simple fix for this specific scenario. A more real-world solution would be to allow one add-in to depend on another and order the activations accordingly. Perhaps I’ll address this in a later post.

When you execute the host, you should see something like this:

As you can see from the output, both the add-ins and the host are utilizing the event hub service. The add-ins are communicating with string subjects, and with a custom subject.

Deployment

Again, deployment hasn't really changed much compared to the skeletal solution. The one big difference is the Subjects project. This project contains a subject type that the add-ins use to communicate. Since both add-ins require access to this type, it must be referenced by each add-in and loaded into their AppDomain. Therefore, the build script for each add-in project copies this file to the add-in’s directory:

<Copy SourceFiles="$(OutputPath)\PublisherAddIn.dll;$(OutputPath)\Subjects.dll" DestinationFolder="..\Host\$(OutputPath)\AddIns\PublisherAddIn" />

Performance

Notably missing from the APIs is a filtering mechanism. That is, a way for publishers or subscribers to filter their interest in a particular event. I excluded this for two reasons:

It was too much effort for the purposes of this post, and would complicate things quite radically.
It would encourage cross AppDomain filtering, which is a potential performance issue.

Any event published to the event hub service has the potential to visit many AppDomains, so it should be used with care and only when necessary. If your add-in requires an event hub service, but it does not need to cross the AppDomain boundary (ie. it is internal to your add-in) you might instead consider something like this. To reiterate, the service discussed in this post should be used only when inter-add-in communication is required. Don’t use it for intra-add-in communications.

A Word of Warning

One thing you must be aware of before using this service is that it circumvents some of the measures MAF takes to protect you from versioning issues. Consider what would happen if you had a custom subject type that was consumed (subscribed to) by many add-ins. Suppose you wanted to alter that custom subject type and those alterations would break existing add-ins. You don’t have the luxury of using adapters to help out because the subject was never explicitly called out in the contracts. Instead, the best you can do is use built-in .NET serialization mechanisms (for example, OptionalFieldAttribute) to provide some compatibility, but this will be limited when compared to using a MAF pipeline.

Because of this, you want to be sure that any custom subject types you create are resilient to change. And when they must change, be sure to ensure that changes are backwards compatible (write some unit tests to verify). And if you simply cannot preserve compatibility, consider defining a new subject type altogether because the alternative is requiring every add-in be recompiled against the new version of the subject type.

Conclusion

An event hub service is imperative for applications where add-ins are required to communicate with each other in a loosely-coupled fashion. The solution I presented in this post allows you to achieve that even when add-ins are in completely separate AppDomains (or even processes) and the host has no knowledge of the types being used to communicate between the add-ins.

Limitations of MAF prevent us from providing an ideal solution - one that leverages generics to provide a strongly-typed API. However, this solution is still very workable. Just be cautious when defining subject types - you don't want them to become a versioning headache, especially considering MAF is designed to help prevent such headaches.

Download the Solution

MAF Gymnastics: Skeletal Solution

2008-06-08T12:55:00.001+01:00

To kick off this series of posts, I've put together a skeletal solution that will be used as a starting point for subsequent posts. MAF requires a lot of plumbing code and infrastructure to be in place before even the simplest example will work. As such, it is prudent for me to avoid duplicating much of that plumbing for each post.

If you download the solution, you'll see that it is comprised of quite a few different projects. Those projects are partitioned into solution folders.

Most of the projects are contained in the "Pipeline" solution folder. It is these projects that implement the pipeline that MAF uses to connect the add-in to the host. The "AddIns" solution folder contains any add-in projects (there is one sample add-in in the download). Finally, the "Host" project is a simple console host that activates any add-ins that it finds.

The Pipeline

The pipeline consists of a bunch of projects:

The Contracts project defines the contracts that MAF will load into both sides of the isolation boundary. It consists of a few simple contracts: IHostContract , IAddInContract and IApplicationAddInContract.

IHostContract provides some properties that add-ins can invoke to get information about their host (name and version, to be specific). IAddInContract defines a single Initialize() method that add-ins implement. This method takes an instance of IHostContract as a parameter, so the add-in can invoke members against the host. IApplicationAddInContract extends IAddInContract but does not add any members. In later posts I will have more than one type of add-in. IAddInContract will serve as a base contract for add-ins.

The AddInViews and HostViews projects define the view of the world for the add-in and host respectively. In this case, they mirror the contracts very tightly, but in later posts we'll see views that differ quite drastically from their corresponding contracts.

The AddInSideAdapters and HostSideAdapters projects provide adapters that MAF uses to adapt views to contracts and vice-versa. The adapters allow the view to be ignorant of the contract and vice-versa, which is required for supporting version tolerance.

Note that I have not used any code generation or tools to generate the pipeline. It is written entirely by hand. The reason I did not use Pipeline Builder is because it is simply not mature enough. I ran into many bugs and limitations when I tried to use it, and it does not give enough control over the generated code.

When I originally decided to ditch Pipeline Builder and write my pipeline by hand, I tried factoring out common adapter functionality into generic base classes. Unfortunately, MAF does not allow adapter classes to inherit from generic classes, even if the adapter itself is closed (I consider this an awful bug and have reported it as such). Moreover, common utility code for adapters cannot be placed into a separate assembly and placed into each adapter's folder because MAF will not load it (unless that assembly is placed into the GAC).

For these reasons, I had to jump through some hoops to factor out this code. Basically, if you look under the "Pipeline\Shared Code" solution folder you'll see some source code files. These files are then linked to from the adapter projects. In effect, the code is stored in one place (good for maintenance) but compiled into two separate projects (to appease MAF).

The utility code itself isn't as clean as it would be if MAF supported adapters with generic base types. However, it's still pretty straightforward. Adapters implement one of the two interfaces (IContractToViewAdapter<TContract> or IViewToContractAdapter<TView>) according to what type of adapter they are. From there, the static Adapt class can be used to convert views to contract and vice-versa. This cuts down on a lot of code repetition, but - again - not as much as I'd like.

The other option I had was to use a simple code generation tool. In a "real" project I would probably do exactly that, but I didn't want to complicate these examples.

The Add-in

Included in the solution is a very simple add-in that simply outputs some information when it is initialized by the host (via the Initialize() method):

[AddIn("Sample add-in")]
public class AddIn : IApplicationAddIn
{
    public void Initialize(IHost host)
    {
        Console.WriteLine("This is the sample add-in, running inside host with name '{0}', version {1}. AppDomain name is '{2}'.", host.Name, host.Version, AppDomain.CurrentDomain.FriendlyName);
    }
}

As you can see, it outputs the details of the host (name and version) and the name of the AppDomain in which it is running (to prove we're being hosted in a separate AppDomain).

The Host

The Host project is a console application that activates and initializes any add-ins it finds that implement the IApplicationAddIn interface. The most pertinent code is contained in the Host.Run() method. This is the code that updates the add-in store, finds and activates any add-ins, and then initializes them.

When you execute this project, you should see something like this:

Deployment

MAF has strict requirements on how the pipeline and add-ins are deployed. If you've read through the MSDN documentation, you'll see recommendations on creating a solution-level output folder and deploying all DLLs within there. I don't like this recommendation because it's non-standard and doesn't deal with multiple configurations (although you could have output\Debug and output\Release folders).

In order to remain somewhat standard and not cause too much confusion, my solution builds into the output folder of the Host project, as you'd expect. Under bin\Debug (or bin\Release) you'll find directories called Pipeline and AddIns. Pipeline segments and add-ins are automatically copied to these directories when you build the solution.

If you're wondering how these files are copied, take a look in one of the project files. For example, crack open the SampleAddIn.csproj file and you'll see this at the end:

<Target Name="AfterBuild">
    <Copy SourceFiles="$(OutputPath)\SampleAddIn.dll" DestinationFolder="..\Host\$(OutputPath)\AddIns\SampleAddIn"/>
</Target>

Conclusion

Well, this has turned into a long post - and we haven't even started yet! MAF is a complex beast - incredibly frustrating at times, and yet very rewarding at others. Hopefully I have set the stage for the subsequent posts, where I will look at how some specific application scenarios can be addressed in MAF.

MAF Gymnastics: Prologue

2008-06-05T19:59:00.001+01:00

The Managed Add-in Framework (MAF) was introduced in .NET 3.5. In short, it is a framework that aims to ease the burden of supporting an add-in ecosystem within your application. It provides features around add-in discovery, loading, and isolation.

The benefits of a good add-in model include:

Security. Add-ins can be isolated and sand-boxed, each with its own set of permissions.
Stability. Isolation also means add-ins have a limited ability to affect each other. If one add-in fails, it does not necessarily affect other add-ins. In addition, it is often possible to switch add-ins from AppDomain isolation to process isolation, which affords even more stability.
Version tolerance. The host application can version independently of add-ins. If the host is developed with care, an add-in written against version 1 of the host can still work against version 2 of the host.
User experience. With add-ins isolated into separate .NET AppDomains, it becomes possible to load and unload add-ins without requiring the host application be restarted.

The key to achieving these benefits is AppDomain isolation. Without it, most of these benefits cannot be realised (version tolerance is the exception). However, supporting AppDomain isolation in your application and add-ins is no walk in the park. It introduces a slew of complexities that will have you tearing your hair out in no time.

This series of blog posts addresses some MAF scenarios that I believe are quite common, but have not so obvious an implementation. I haven't finalized the set of scenarios I'll be covering, but I have two written, with a further two in mind.

Note that I do assume the reader has a fundamental understanding of MAF throughout this series. If you're just getting started with MAF, you should check out this section in MSDN and read this series later.

In the next post I'll provide a skeletal MAF solution which we'll be using as a starting point for subsequent posts.

PS3 Power Consumption

2008-06-04T19:35:00.002+01:00

From this article:

Our tests found that leaving a Playstation 3 on while not in use would cost almost... five times more than it would take to run a refrigerator for the same yearly period

And, in response, I have this to say:

Yep, that's my PS3 power consumption in standby. A massive 4 watts. And, in comparison, here is my microwave in standby (I can't reach my fridge socket):

All I can think of is they measured with wireless on, which may consume more power, but if they at least published specifics that would be helpful. I couldn't track down the supposed original article on choice.com.au.

UPDATE: Nope, just tested and even with wireless on it still uses a measly 4 watts when on standby.

UPDATE 2: OK, I tracked down the original article. It's here. It turns out they were misquoted in the yahoo post. The incorrect quote is "an Australian consumer agency study has found that videogame consoles ... are major electricity guzzlers, even when left on stand-by". However, the article itself points out that you should put consoles on stand by when not in use. Wow, revolutionary advice. Who the hell would leave a console on when they're not playing it? That's like leaving the TV on and muting it when you're not watching it. Newsflash: refrigerators are designed to be on 24/7; consoles are not.

Gauntlet V1 Released

2008-05-18T17:53:00.001+01:00

Today I released V1 of Gauntlet, which is a .NET code generation tool that integrates seamlessly into your build process. I've been working away at it on and off (mainly off) for a few months now, so it felt somewhat therapeutic to finally release it.

There are a wide variety of uses for Gauntlet, but here are a couple of examples:

Gaining control over the proxy classes generated for web / WCF services
Generating large parts of your domain / business layer
Generating constants or enumerations from sample data

Head on over to the Gauntlet CodePlex site for more information.

Expander and VisualBrush

2008-05-15T19:47:00.001+01:00

Today I was trying to implement some drag and drop spiffiness by including a semi-transparent preview of the item being dragged. Basically when the user starts dragging something, it "tears off" and follows the mouse cursor, so they can see exactly what they're dragging. Like I said: spiffy. Don't deny it.

Sounds like a job for VisualBrush, and indeed it is. I was able to get this working pretty nicely, but noticed a weird problem with Expanders. Basically, if you expand and then collapse an Expander, and then use a VisualBrush to clone it, the VisualBrush will clone both the header of the Expander, and the white space the Expander previously occupied when expanded.

Huh?

Let me explain with pictures. Say you've got an Expander:

And you then expand it, and subsequently collapse it:

Then then your code creates a VisualBrush around the Expander like this:

Rect rect = new Rect(0, 0, _expander.RenderSize.Width, _expander.RenderSize.Height);
VisualBrush visualBrush = new VisualBrush(_expander);
_rectangle.Fill = visualBrush;

What you get looks like this:

What the...? What's happened here is what I described above. The size of the Rectangle hosting the VisualBrush is correct. However, the snapshot the VisualBrush has taken of the Expander is incorrect because it includes white-space below the header, even though the Expander is collapsed.

As I discovered, other people have come up against this problem too, but no solution was apparent. Thus, I set about to find one.

And here it is:

Rect rect = new Rect(0, 0, _expander.RenderSize.Width, _expander.RenderSize.Height);
VisualBrush visualBrush = new VisualBrush(_expander);

visualBrush.ViewboxUnits = BrushMappingMode.Absolute;
visualBrush.Viewbox = new Rect(_expander.TranslatePoint(rect.TopLeft, this), rect.Size);

_rectangle.Fill = visualBrush;

This time we get the expected result:

The trick is to use absolute units for the view box, and to translate the Rectangle relative to the host. This doesn't really explain the bug, but it does work around it. You can download the sample project (pictured in the images above) right about here.

Dispatcher Frames

2008-04-28T20:09:00.001+01:00

With scant exception, WPF controls must be accessed from the same thread on which they were created. Because of this, we say they have 'thread affinity'.

In WPF, thread affinity is realised via DispatcherObjects, which can be accessed directly only on the thread on which they were created. Alternatively, they can be accessed via their Dispatcher. The Dispatcher contains methods for adding operations to a queue which is processed on the Dispatcher's thread. Each thread has at most one Dispatcher instance associated with it (which is created on demand). Many WPF classes - including controls such as TextBox and Button - inherit from DispatcherObject. This means that accessing instances of these controls must be done on the control's thread, possibly via the control's Dispatcher.

You may have noticed a type called DispatcherFrame whilst browsing MSDN (as you may be inclined to do on a Saturday night. Or not). That's what I want to discuss in this post.

You can think of a DispatcherFrame as something that forces operations to be processed until some condition is met. Every WPF application has at least one DispatcherFrame that is created when you run the application. It will continue pumping operations until the application is shut down.

At times it can be useful to pump operations until some condition of your own is met. Perhaps your code is executing on the UI thread and you want to empty the queue of operations in the Dispatcher to force control and screen updates. In the Winforms world, this is achieved via a call to Application.DoEvents(). In WPF, there is no equivalent method, but we can easily simulate one:

public static void DoEvents(this Application application)
{
    DispatcherFrame frame = new DispatcherFrame();
    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background, new ExitFrameHandler(frm => frm.Continue = false), frame);
    Dispatcher.PushFrame(frame);
}

private delegate void ExitFrameHandler(DispatcherFrame frame);

The above code is part of a small demo project, which you can download here. It adds a DoEvents() method to WPF's Application class. The DoEvents() method adds a Background priority operation to the Dispatcher's queue, and then pushes a new frame that pumps operations until that operation is processed. As a result, all other operations that were already queued in the Dispatcher will be processed. There are several important things I need to point out here:

1. Adding the new operation to the Dispatcher is done asynchronously. As such, the operation is not processed until we call PushFrame().
2. The choice of Background as the priority is important. If we were to choose a higher priority (such as Render), then we would potentially leave lower-priority operations in the queue after the frame had exited. That's because our operation would be executed prior to those lower-priority operations, and thus we'd end the frame too soon. Perhaps there's value in adding a DoEvents() overload that accepts a minimum priority of operations that should be executed, but I haven't included one in the download.
3. Operations in a Dispatcher are not associated with a particular DispatcherFrame. A DispatcherFrame can cause any queued operation to be processed, not just those added after the frame is pushed.
4. The code assumes it is running on the thread whose Dispatcher should be pumped.

A DoEvents() implementation is nice for illustrating the utility of DispatcherFrames (indeed it is used in the MSDN documentation too), but I believe it is unnecessary. As you can see in the demo, it is possible to simulate DoEvents() in a much simpler fashion: by synchronously adding a low-priority no-op to the Dispatcher's queue:

public static void DoEvents(this Application application)
{
    Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Background, new VoidHandler(() => { }));
}

private delegate void VoidHandler();

The call to Invoke() will not return until our operation has been processed, which won't be until all higher priority operations are processed. Therefore, the end result is the same - all queued operations are pumped (apart from those with a priority lower than Background, but I'm ignoring that in this post).

So where would you use a DispatcherFrame?

I recently had need for one at my day job. We have a splash screen that usually just shows progress information (downloading files, searching for modules etcetera) but sometimes needs to ask the user which catalog they would like to load (a catalog is just a set of modules).

The splash presenter tries as hard as it can not to ask the user (if they only have one catalog, or it has been specified via a command line switch then it doesn't need to ask), but if it does need to, it delegates a call to the splash view on the UI thread. This call needs to return the catalog that the user selected. However, it has been called on the UI thread, so obtaining a catalog from the user requires pumping operations so they can select one from a list. The code looks like this:

public Catalog SelectCatalog(ICollection<Catalog> availableCatalogs)
{
    StatusLabel = "Please select a catalog:";
    _catalogsItemsControl.ItemsSource = availableCatalogs;

    _catalogSelectionFrame = new DispatcherFrame(true);
    Dispatcher.PushFrame(_catalogSelectionFrame);
    StatusLabel = "Thank you";     _catalogsItemsControl.ItemsSource = null;

    return _selectedCatalog;
}

This method sets up the catalogs for the user to select from by assigning them to an ItemsControl (which renders each catalog as a hyperlink). It then pushes a new DispatcherFrame, which blocks until the frame is stopped. After the DispatcherFrame finishes, the selected catalog is returned. The only way to end the frame is by clicking on one of the hyperlinks representing the catalogs. Each hyperlink rendered by the ItemsControl has a Click handler as follows:

private void _hyperlink_Click(object sender, EventArgs e)
{
    _selectedCatalog = (sender as Hyperlink).DataContext as Catalog;
    _catalogSelectionFrame.Continue = false;
}

When a hyperlink is clicked, I store the selected catalog and then end the DispatcherFrame. As a result, the code that pushed the DispatcherFrame will continue execution. Note that I would not have to manually track the selected catalog if I was using a ListBox, but for now I'm using with the ItemsControl because it was simpler to style.

Above I suggested that the only way to end the DispatcherFrame was by setting DispatcherFrame.Continue to false. That's not the entire story. DispatcherFrames may also be asked to stop during application shutdown. When that happens, DispatcherFrames will, by default, comply with the request. However, there is a constructor overload that allows you to bypass this behaviour and instead continue processing operations until your condition is met. This might be useful for a short-lived frame whose completion is critical to the correctness of your application.

Download Demo

Berlin

2008-04-19T12:51:00.001+01:00

Last weekend we headed to Berlin. We stayed south-east of the city, in the appropriately-named Holiday Inn. Friday night was basically a write-off, since we didn't arrive until around 10PM. On Saturday we had a late breakfast and then headed into the City.

Unfortunately, the S9 line which connected us to the centre of the city was under weekend maintenance, so it was a time-consuming process getting anywhere. This is one of the train stations we waited at (Betriebsbahnhof Schöneweide):

Eventually we made it into the city and headed to the Berlin Zoo, which was fantastic:

(poor photo, but I just love black panthers. All cats want to be them)

On Sunday we wanted to visit Fernsehturm, which is a 365 metre high tower in central Berlin. After waiting for 40 minutes or so, we gave up because the line wasn't moving. However, here are some pictures of the tower:

The people in Berlin were very nice, and the weather was perfect. Overall it was a great weekend, although we would have liked more time to fully appreciate it.

SCSFContrib 1.5

2008-04-18T18:19:00.001+01:00

Admittedly, it has been far too long, but the SCSFContrib team have finally released version 1.5. The highlights of this release are:

New Features
- All solution and projects migrated to Visual Studio 2008 and .NET Framework 3.5.
- DockPanelWorkspace and FormWorkspace added to SCSFContrib.CompositeUI.WinForms project.
- Action Catalog Service added to SCSFContrib.Services project.
- Added Visual Studio templates and Installer for Trusted and Untrusted modules in the WPF/CAB Shell.
New Samples
- BankTeller implementation using a pure WPF application.
- Demo Application with its Demo Script that provides step-by-step instructions to create a SC-SF application.
- OrdersManager application that demonstrates how to integrate the CAB and SC-SF with Windows Workflow Foundation.
- TestSuite reference application showing DockPanelWorkspace usage.
- WPF CAB Shell sample application (source code, libs and unit tests).

You can head over to the SCSFContrib CodePlex site to download. Enjoy!