the Joy of Code

Silverlight out-of-browser and initParams

Josh Twist — Wed, 21 Oct 2009 13:26:06 GMT

Silverlight 3 supports a very cool 'deployment model' where you can run the Silverlight Application 'out-of-browser' (OOB) and kick it off from your start menu. It even works offline. This is the future, get to like it.

However, because the plug-in is no longer hosted in your page you lose all those juicy settings and, perhaps worst of all, you initialization parameters aren't available when the app runs OOB. This is frustrating because a lot of people pass in settings from their host web-application's web.config file using this very mechanism.

However, it only takes a little bit of code to work around this scenario by caching the initParams in isolated storage whenever the applicaiton is run in-browser. Here's some code that does just that:

private void Application_Startup(object sender, StartupEventArgs e)
{
    var mp = new MainPage();
    this.RootVisual = mp;

    IDictionary<string, string> initParams = LoadInitParams(e);

    // this just adds the init params to the MainPage for demo purposes only
    foreach (var kv in initParams)
    {
        mp.LayoutRoot.Children.Add(new TextBlock { Text = kv.Key, FontStyle = FontStyles.Italic });
        mp.LayoutRoot.Children.Add(new TextBlock { Text = kv.Value, Margin = new Thickness(5,0,0,0) });
    }
}

private static IDictionary<string, string> LoadInitParams(StartupEventArgs e)
{
    IDictionary<string, string> initParams;

    // if running out of browser retrieve 'initParams' from cache
    if (Application.Current.IsRunningOutOfBrowser)
    {
        using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
        using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream("initParams.txt", System.IO.FileMode.Open, isf))
        {
            DataContractSerializer ser = new DataContractSerializer(typeof(Dictionary<string, string>));
            initParams = (Dictionary<string, string>)ser.ReadObject(stream);
        }
    }
    // otherwise write initParams to cache
    else
    {
        initParams = e.InitParams;

        using (IsolatedStorageFile isf = IsolatedStorageFile.GetUserStoreForApplication())
        using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream("initParams.txt", System.IO.FileMode.Create, isf))
        {
            DataContractSerializer ser = new DataContractSerializer(typeof(Dictionary<string, string>));
            ser.WriteObject(stream, initParams);
        }
    }
    return initParams;
}

Easy peasy.

One recommendation here though is that you probably want a layer of indirection between Initalization Parameters and your 'silverlight configuration' in this case. The reason for this is the initParams will only get updated when you run the app in-browser. It's possible that your user will never run the app in-browser again. And even if the XAP gets updated your new parameters may never be seen, unless the app runs in-browser. So I'd recommend storing a static and constant URL in your initParameters that specifies an XML file (or web service) on the web server that contains your silverlight configuration.

You can then download this at will, even out-of-browser, whenever the network is available.

Five minute recipe for a decent BoolToVisibilityConverter

Josh Twist — Mon, 12 Oct 2009 09:26:55 GMT

There are a bunch of IValueConverters that WPF probably should ship with... MultiplyConverter, AdditionConverter etc. Rather oddly it does ship with one: The BooleanToVisibilityConverter:

However, I'm not a huge fan of the implementation as it gives me little control over what true and false actually map to. For example, should false be Collapsed or Visible? What if I want to invert? For these reasons I always craft my own (I really must start a codeplex project at some point to keep all these converters). Here it is:

public class BoolToVisibilityConverter : MarkupExtension, IValueConverter
{
    public BoolToVisibilityConverter()
    {
        TrueValue = Visibility.Visible;
        FalseValue = Visibility.Collapsed;
    }

    public Visibility TrueValue { get; set; }
    public Visibility FalseValue { get; set; }

    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        bool val = System.Convert.ToBoolean(value);
        return val ? TrueValue : FalseValue;
    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        return TrueValue.Equals(value) ? true : false;
    }

    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return this;
    }
}

As discussed in a previous post, I've used my Converters as MarkupExtensions tip but I've also made the TrueValue and FalseValue completely configurable so there's a clear route for both inversion and choice between Collapsed and Hidden. In fact, you could even have True==Collapsed and False==Hidden if you liked - not sure what you'd use that for though. Note that we set sensible defaults in the constructor.

Here's how to use it:

<StackPanel VerticalAlignment="Bottom">
    <StackPanel.Resources>
        <local:BoolToVisibilityConverter FalseValue="Collapsed" x:Key="btvc" />
    </StackPanel.Resources>
    <CheckBox x:Name="HideOrShowCheck">Hide or show the text...</CheckBox>
    <TextBlock Text="Hello World!" Visibility="{Binding ElementName=HideOrShowCheck, Path=IsChecked,Converter={StaticResource btvc}}" />
</StackPanel>

Or, my preferred way:

<StackPanel VerticalAlignment="Bottom">
    <CheckBox x:Name="HideOrShowCheck">Hide or show the text...</CheckBox>
    <TextBlock Text="Hello World!" Visibility="{Binding ElementName=HideOrShowCheck, Path=IsChecked,Converter={local:BoolToVisibilityConverter FalseValue=Collapsed}}" />
</StackPanel>

Happy converting.

MultiBinding for Silverlight 3

Josh Twist — Wed, 23 Sep 2009 10:27:55 GMT

One of the key binding features missing from Silverlight 3 is MultiBinding and IMultiValueConverter support. In this post I'll walk through a custom implementation that uses a few tricks that you may want to leverage elsewhere.

First of all, I wanted to re-create the IMultiValueConverter from WPF in it's entirety. Here it is:

public interface IMultiValueConverter
{
    object Convert(object[] values, Type targetType, object parameter, CultureInfo culture);
    object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture);
}

That was easy. Now for the actual MultiBinding. In WPF a MultiBinding looks like this:

<TextBlock Name="textBox2" DataContext="{StaticResource NameListData}">
    <TextBlock.Text>
        <MultiBinding
            Converter="{StaticResource myNameConverter}"
            ConverterParameter="FormatLastFirst">
                <Binding Path="FirstName"/>
                <Binding Path="LastName"/>
        </MultiBinding>
    </TextBlock.Text>
</TextBlock>

Ideally I'd have liked to recreate this for Silverlight but without support for custom MarkupExtensions that's just not happening. Instead, we'll have to use another trick where we implement a non-visual FrameworkElement. We use a FrameworkElement because we want DependencyProperties that support Bindings and these have to belong to FrameworkElement in Silverlight (a DependencyObject isn't good enough in SL3 as it is in WPF). No matter.

The other trick is that we have to add this element to the Visual Tree. What? Yes, I know, it feels like a hack but really it isn't. Even the RIA team do it so it must be OK. The key thing is that our element is non-visual so it doesn't contribute to the Render pipeline (has 0x0 size etc...). This is what it might look like in use:

<binding:MultiBinding x:Name="mb" Converter="{StaticResource intsToBrushConverter}"
    NumberOfInputs="3"
    Input1="{Binding ElementName=red, Path=Value, Mode=TwoWay}"
    Input2="{Binding ElementName=green, Path=Value, Mode=TwoWay}"
    Input3="{Binding ElementName=blue, Path=Value, Mode=TwoWay}" />

<Border Background="{Binding ElementName=mb, Path=Output}" Margin="5"/>

<StackPanel Orientation="Horizontal" HorizontalAlignment="Center" Grid.Row="1">
    <Slider x:Name="red" Minimum="0" Maximum="255" Margin="5" Orientation="Vertical"/>
    <Slider x:Name="green" Minimum="0" Maximum="255" Margin="5" Orientation="Vertical" />
    <Slider x:Name="blue" Minimum="0" Maximum="255" Margin="5" Orientation="Vertical" />
</StackPanel>

You might have guessed that I'm creating a Color Selector control. Wanna' see it in action? Go on then (can't see it? click here).

Here's the BrushConverter (IMultiConverter) that's used by the MultiBinding:

public class IntsToBrushConverter : IMultiValueConverter
{
    public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        byte r = System.Convert.ToByte(values[0]);
        byte g = System.Convert.ToByte(values[1]);
        byte b = System.Convert.ToByte(values[2]);
        return new SolidColorBrush(Color.FromArgb(Byte.MaxValue, r, g, b));
    }

    public object[] ConvertBack(object value, Type[] targetTypes, object parameter, System.Globalization.CultureInfo culture
    {
        SolidColorBrush brush = (SolidColorBrush)value;
        return new object[] { brush.Color.R, brush.Color.G, brush.Color.B };
    }
}

Easy peasy. Want the code? Go on then:

Usual disclaimers apply - this is demoware and used very much at your own risk.
Download Source (12 KB)
Please leave some feedback in the comments if you like it.

Important Notes

You may have noticed a few strange features about our MultiBinding, e.g. how the inputs are specified on a number of Input1, Input2 and Input3 properties instead of on child controls. That's just the way it is I'm afraid (because Bindings only work on members of the visual tree, and since this is a non-visual element any child elements aren't part of the visual tree), and because of this you have to specify the NumberOfInputs you want - my version supports up to 5.

<binding:MultiBinding x:Name="mb" Converter="{StaticResource intsToBrushConverter}"
    NumberOfInputs="3"
    Input1="{Binding ElementName=red, Path=Value, Mode=TwoWay}"
    Input2="{Binding ElementName=green, Path=Value, Mode=TwoWay}"
    Input3="{Binding ElementName=blue, Path=Value, Mode=TwoWay}" />

You really can drop this control pretty much anywhere in your visual tree but it makes most sense to keep it close to the parts that need it. As always, your own mileage may vary. Any feedback appreciated in the comments.

.NET Naming Conventions

Josh Twist — Tue, 08 Sep 2009 09:26:35 GMT

I often get asked about the Naming Conventions I adhere to when writing code (C#, naturally).

It made sense to share these in a blog post so I can refer to it in future.

Some of these guidelines (well, one, the underscore on private fields) are negotiable as a matter of style. However, the public stuff is non-negotiable. For this is how .NET APIs should be and failure to adhere to this reflects badly on your code. No, no, no.

I thought a good way to present this would be an example class demonstrating the rules and some comments to help, so here goes:

using System;

// Namespaces are PascalCased
namespace TheJoyOfCode.NamingConventions
{
    // Class names are PascalCased
    public class ExampleClass
    {
        // All public fields, including constants are PascalCased
        public static const string PiAsAString = "3.14";

        // All private fields are camelCased with an underscore [1]
        private readonly string _privateMember;

        // All protected members are PascalCased
        protected int ProtectedField = 12;

        // All internal members are PascalCased
        internal int InternalField = 13;

        // All private methods are PascalCased
        // *** NOTE - All parameters are camelCased
        private double Multiply(double valueA, double valueB)
        {
            // local variables (scoped within a method) are camelCased (no underscore)
            double result = valueA * valueB;
            return result;
        }

        // All private Properties are PascalCased
        // *** NOTE - Acronyms of 2 characters are UPPERCASED (e.g. UI, IO)
        private string UIElementName { get; }

        // All (public and private) properties are PascalCased
        // *** NOTE - Acronyms longer than 2 characters are PascalCased (e.g. Html, Xml)
        public int HtmlLength { get; set; }

        // All public methods are PascalCased
        // *** NOTE - All parameters are camelCased
        // *** NOTE - Abbreviations are not treated as Acronyms (so _Id_entification is Id, not ID).
        private void AlignObjectById(string id, Alignment alignment)
        {
            throw new NotImplementedException();
        }

        // Nested classes are PascalCased, even Private ones
        private class NestedClass : IDisposable
        {
            public void Dispose()
            {
                throw new NotImplementedException();
            }
        }
    }

    // Enums are PascalCased and not plural (unless marked [Flags] in which case the name should be plural)
    public enum Alignment
    {
        // Enum members are PascalCased
        Top,
        Bottom,
        Left,
        Right,
    }
}

// [1] - Note the underscore isn't as recommended by StyleCop but since it applies only to private members, can be considered a matter of style and one that I personally use.

... and as for #region blocks I do not use regions and I don't negotiate with terrorists either.

A Suck Less Event Aggregator for Prism?

Josh Twist — Tue, 04 Aug 2009 01:27:37 GMT

I heard on twitter the other day (Yes, I now tweet occasionally. If you'd like to waste literally seconds of your day you can follow me at joshtwist) that some folks at an Alt.Net UK event where giving P&P and Prism a rough ride. Specifically, they had some issues with the EventAggregator - citing Jeremy Miller's criticisms in this post Braindump on the Event Aggregator Pattern.

I need to say up front that I really like the EventAggregator in Prism - it's one of my favourite bits. However, I have to agree with some of the feedback. I've always found it odd that I have to go to the EventAggregator and ask for an 'event' object. Especially because the thing I get back isn't an event, but the 'bus' through which events travel.

CustomerSelectedEvent cse = eventAggregator.GetEvent<CustomerSelectedEvent>();
cse.Subscribe(c => CustomerHasBeenSelected(c));

// meanwhile, elsewhere...

CustomerSelectedEvent cse = eventAggregator.GetEvent<CustomerSelectedEvent>();
cse.Publish(customer);

However, once I've learned the API I've never found it obstructive. Nonetheless - I wondered, how hard would it be to create a wrapper that makes the Event Aggregator look something like you might expect it to look?

public interface ISuckLessEventAggregator
{
    void SendMessage<T>(T message);
    void Subscribe<T>(Action<T> action);
    void Subscribe<T>(Action<T> action, bool keepSubscriberReferenceAlive);
    void Subscribe<T>(Action<T> action, Microsoft.Practices.Composite.Presentation.Events.ThreadOption threadOption, bool keepSubscriberReferenceAlive, Predicate<T> where);
    void Unsubscribe<T>(Action<T> action);
}

The interface would look something like that I guess. And it would be used like so.

eventAggregator.Subscribe<Customer>(c => CustomerHasBeenSelected(c));

// meanwhile, elsewhere...

eventAggregator.Send(customer);

That certainly feels a bit better. However, there's no 'topic' described so this feels like a poor usage of the new interface as I can't distinguish Customer *selection* from other events involving the Customer type. Maybe this is better:

public class CustomerSelectedEvent
{
    public Customer Customer { get; set; }
}

// elsewhere

eventAggregator.Subscribe<CustomerSelectedEvent>(c => CustomerHasBeenSelected(c.Customer));

// meanwhile, elsewhere...

eventAggregator.Send(new CustomerSelectedEvent { Customer = customer} );

Now I prefer this over the existing pattern for a number of reasons

It's just easier to read
The 'event' class, CustomerSelectedEvent, is a POCO - no dependencies on the Prism pieces.

And how might this implementation look? Here's a first shot:

using System;
using Microsoft.Practices.Composite.Events;
using Microsoft.Practices.Composite.Presentation.Events;

public class SuckLessEventAggregator : ISuckLessEventAggregator
{
    private readonly IEventAggregator _eventAggregator;

    public SuckLessEventAggregator(IEventAggregator eventAggregator)
    {
        _eventAggregator = eventAggregator;
    }

    private CompositePresentationEvent<T> GetEventBus<T>()
    {
        var bus = _eventAggregator.GetEvent<CompositePresentationEvent<T>>();
        return bus;
    }

    public void SendMessage<T>(T message)
    {
        var bus = GetEventBus<T>();
        bus.Publish(message);
    }

    public void Subscribe<T>(Action<T> action)
    {
        var bus = GetEventBus<T>();
        bus.Subscribe(action);
    }

    public void Subscribe<T>(Action<T> action, bool keepSubscriberReferenceAlive)
    {
        var bus = GetEventBus<T>();
        bus.Subscribe(action, keepSubscriberReferenceAlive);
    }

    public void Subscribe<T>(Action<T> action, ThreadOption threadOption, bool keepSubscriberReferenceAlive, Predicate<T> where)
    {
        var bus = GetEventBus<T>();
        bus.Subscribe(action, threadOption, keepSubscriberReferenceAlive, where);
    }

    public void Unusbscribe<T>(Action<T> action)
    {
        var bus = GetEventBus<T>();
        bus.Unsubscribe(action);
    }

    // You'd probably have more overloads but I'll wait for C# 4's Optional keyword :)
}

Does this feel better?

I realise that it doesn't address all of Jeremy's concerns (it's just the result of a short train journey's work so far). However, some of them I just don't agree with.

For example:

"2. The listeners should have little or preferably NO/ZILCH/NADA coupling to the event aggregator."

I'd much prefer an explicit dependency on the EventAggregator than a relatively implicit one to an IoC behavior. In either case, this is more of a religious argument than a technical one.

I also realise that most of this could have been implemented in Extension Methods but I think a separate, uncluttered API would be more intuitive.

Thoughts? Any holes in my quick implementation?

How to work with PropertyChanged's smelly name string

Josh Twist — Sun, 02 Aug 2009 10:52:35 GMT

Karl posted an interesting article recently INotifyPropertyChanged – How to remove the Property Name String Code Smell.

It'a nice implementation and the resulting code certainly looks a whole better. As Karl notes the biggest problem this approach faces is one with performance.

Notably, the proposed implementation is a lot slower when there are listeners wired up to the INotifyPropertyChanged plumbing.

The performance could be improved by caching the StackTrace based on an accompanying static key for each property, e.g.

private static readonly object _namePropertyKey = new object();

public string Name
{
    get { return _name; }
    set
    {
        _name = value;
        OnPropertyChanged(_namePropertyKey);
    }
}

However, this is probably just as prone to runtime errors in case somebody uses the wrong key with the wrong property.

With respect to the importance of performance then Karl is right to note that your users can only type so fast. But in some models and viewmodels, say containing a few hundred points that will be represented on a chart. That hit in performance could REALLY hurt.

My approach to this problem is to leave the smelly string where it is and automate the testing process using the Automatic Class Tester. This will automaticaly test that your properties are wired up appropriately and, if your class implements INotifyPropertyChanged it will also check that the appropriate PropertyChanged string name is fired.

Silverlight, Validation and MVVM - Part II

Josh Twist — Fri, 31 Jul 2009 07:51:40 GMT

The new Validation states for controls in Silverlight 3 sure look nice but there are a number of limitations. For starters, you can only invoke them through:

An exception thrown by a bound property setter
An exception thrown by a ValueConverter

The latter feels particularly unsavoury as you'll need to reuse the same converter wherever you want to bind to that property - a big violation of the DRY principle.

You can't even use the new ValidationAttributes from System.ComponentModel.DataAnnotations. Well, actually you can but you'd have to this inside the setter:

[Range(18, int.MaxValue, ErrorMessage="Must be 18 or over")]
public int Age
{
    get { return _age; }
    set
    {
        Validator.ValidateProperty(value, new ValidationContext(this, null, null)
        {
            MemberName = "Age",
        });
        _age = value;
        OnPropertyChanged("Age");
    }
}

(You can imagine an enhancement to this pattern using the SetValue concept I shared with my new snippets the other day).

What's particularly tricky is to display the invalid state if the value is never changed by the user. For example, you have a name field that is required:

[Reguired(ErrorMessage="Name is required")]
public string Name

This is bound to a TextBox:

<TextBox Text="{Binding Name, Mode=TwoWay, ValidatesOnExceptions=True, NotifyOnValidationError=True}" x:Name="NameTextBox" />
<Button Content="Save" x:Name="SaveButton" />

The problem is, the user might click save without ever entering the a name. Oh no!

Sure, we can catch that in our code (using the Validator type again, for example). However, there's no easy way of forcing the control to display the error. The only way to achieve this is to force the binding to update programmatically, like so:

BindingExpression binding = NameTextBox.GetBindingExpression(TextBox.TextProperty);
binding.UpdateSource();

Now, to get this working on any scale is going to require code-behind. Lots of code-behind. And everybody knows I hate this. The whole validation story at the moment isn't going to play at all well with Model-View-ViewModel (MVVM).

What we need is an easy way to Update all bindings from our ViewModel...

And so, I set about finding a more declarative way of achieving solving. My approach builds on my previous post Silverlight Validation and ViewModel.

Re-introducing the ValidationScope

In this update - the ValidationScope class becomes much more important and has more to offer than just an attached properties/behavior.

It now becomes an integral part of your ViewModel. Let's walk through a scenario. Here we'll have a ViewModel that exposes a Person property of type Person:

// properties snipped down for brevity
public class Person
{
    [Required(ErrorMessage= "Name is required")]
    public string Name {}

    [Required(ErrorMessage = "Salutation is required")]
    public string Salutation {}

    [Range(0, int.MaxValue, ErrorMessage = "Must be over 18")]
    public int Age {}
}

Nice and easy. Now the validation scope comes into play - we add an instance to our ViewModel because we'll access it via binding. To be honest, this could go almost anywhere you like provided it's accessible in a Binding (resources, in the Person class itself, anywhere you like!).

// properties snipped down for brevity
public class MainViewModel : INotifyPropertyChanged
{
    public ObservableCollection<string> Salutations {}
    public Person Person {}
    public ValidationScope PersonValidationScope {}
}

So there's our model and our ViewModel. Now for some view - our Xaml (again, simplified for brevity):

<StackPanel local:ValidationScope.ValidationScope="{Binding PersonValidationScope}">
        <TextBox
            Text="{Binding Person.Name, Mode=TwoWay, ValidatesOnExceptions=True, NotifyOnValidationError=True}"
            local:ValidationScope.ValidateBoundProperty="Text" />
        <TextBox
            Text="{Binding Person.Age, Mode=TwoWay, ValidatesOnExceptions=True, NotifyOnValidationError=True}"
            local:ValidationScope.ValidateBoundProperty="Text" />
        <ComboBox
            ItemsSource="{Binding Salutations}"
         SelectedItem="{Binding Person.Salutation, Mode=TwoWay, NotifyOnValidationError=True, ValidatesOnExceptions=True}"
    local:ValidationScope.ValidateBoundProperty="SelectedItem" />
    <Button Content="Save" Click="SaveButtonClick" />
</StackPanel>

And the code-behind:

//Note - I'd normally use Prism's DelegateCommand and commanding support to avoid this code-behind but don't want to muddy the example
private void SaveButtonClick(object sender, RoutedEventArgs e)
{
_personViewModel.Save();
}

Finally, the Save method on the ViewModel

public void Save()
{
    // This causes all registered bindings to be updated
    PersonValidationScope.ValidateScope();
    if (PersonValidationScope.IsValid())
    {
        // Save changes!
    }
}

How it all works

Whilst getting here took me a whole morning of confusion - it's actually quite straightforward.

First, we use an attached behavior to pass the FrameworkElement we want to be the conceptual 'validation scope' within the VisualTree to our actual ValidationScope instance:

<StackPanel local:ValidationScope.ValidationScope="{Binding PersonValidationScope}">

Then we specify the property who is bound and might need a refresh for each control:

<TextBox local:ValidationScope.ValidateBoundProperty="Text" />
<ComboBox local:ValidationScope.ValidateBoundProperty="SelectedItem" />

Sadly, this is really a violation of the DRY principle anyway but it does have the added advantage of having to opt in your Bindings to the ValidationScope. Finally, when we're ready, we tell the ValidationScope to update all the bindings:

PersonValidationScope.ValidateScope();

This kicks the process into action with a crawl of the VisualTree inside the FrameworkElement registered as our scope (the StackPanel in this case) and hunts out any attached ValidateBoundProperty properties wired to controls. When it finds them it looks for the appropriate DependencyProperty (Text and SelectedItem in our demo)

demoware

If you're interested in this you'll want to see a working demo and the source code. Here's the former and the latter will follow in a minute. To bush the barrier, we actually have two validation scopes in the same view, side-by-side

Before you get to the source - bear in mind this is demoware/spike standard only and probably needs work. The usual disclaimers apply. Here are just some thing that haven't even been thought about in the current implementation:

binding to the same ValidationScope from two different FrameworkElements
performance could be improved, quite a bit of reflection
nested ValidationScopes
many more I'm sure

Finally, before you rush off make sure to double check that the new DataForm control and/or .NET RIA Services isn't really what you need to solve your validation requirements.

The source

Get it here and remember, this may damage your health and your house is at risk if you use it as it is: Download Source (15 KB)

Feedback

Please let me know what you think of this approach, if you go on to use it and, if so, what changes you made. Also, let me know if you have any suggestions or questions - either via the comments below or via e-mail through the contact us page.

New snippets for Silverlight and WPF

Josh Twist — Thu, 30 Jul 2009 01:44:41 GMT

A while back I posted some snippets for WPF here: WPF Snippets for Visual Studio. I've been wanting to update these for a while now and finally got around to it this morning. Here are the new snippets.

basevm

This is a snippet that effectively replaces the inpc snippet (although that is still included for demos etc). The primary addition is that of a SetValue method that actually checks if values have been changed before raising the PropertyChanged event. Here's what the snippet looks like.

// TODO - consider making this class abstract if it is used as a base class
public class ViewModelBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected virtual void OnPropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler pceh = PropertyChanged;
        if (pceh != null)
        {
            pceh(this, new PropertyChangedEventArgs(propertyName));
        }
    }

    /// <summary>
    /// Set's the value of the target parameter (replacing the reference) if the value has changed. Also fires
    /// a PropertyChanged event if the value has changed.
    /// </summary>
    /// <typeparam name="T">The type of the property</typeparam>
    /// <param name="target">The target to be swapped out, if different to the value parameter</param>
    /// <param name="value">The new value</param>
    /// <param name="changedProperties">A list of properties whose value may have been impacted by this change and whose PropertyChanged event should be raised</param>
    /// <returns>True if the value is changed, False otherwise</returns>
    protected virtual bool SetValue<T>(ref T target, T value, params string[] changedProperties)
    {
        if (Object.Equals(target, value))
        {
            return false;
        }

        target = value;

        foreach (string property in changedProperties)
        {
            OnPropertyChanged(property);
        }

        return true;
    }
}

Note that it's also hinting that this would make a good base class for your ViewModel classes - but that's up to you.

propsv

This is the accompanying replacement for basevm - trumping propnp (although again, that is included for inpc users).

private int _age;

public int Age
{
    get { return _age; }
    set
    {
        SetValue(ref _age, value, "Age");
    }
}

SetValue takes a list of strings specifying what PropertyChanged events should fire. This is because you often want to fire Changes for dependant properties. E.g.

public bool IsLegalDrinkingAgeInUK
{
    get { return _age > 18; }
}

private int _age;

public int Age
{
    get { return _age; }
    set
    {
        SetValue(ref _age, value, "Age", "IsLegalDrinkingAgeInUK");
    }
}

SetValue also returns a bool in case you want to do some conditional processing based on whether the value was actually changed or not, e.g.:

public int Age
{
    get { return _age; }
    set
    {
        if (SetValue(ref _age, value, "Age", "IsLegalDrinkingAgeInUK"))
        {
            DoSomethingWhenAgeChanges();
        }
    }
}

depprop

Finally, I've really been wanting to add this to my snippets. Basically some enhancements to the built-in propdp with these new features:

Adds a Change handler for the dependency property
This one favours Silverlight by going for PropertyMetadata, instead of UIPropertyMetadata (WPF users just put the 'UI' back in)
Sets the default value of the dependency property using the default(type) syntax - should avoid nasty errors when you leave '0' instead of '0d' for a double,e tc.

Here's how it looks:

public double Minimum
{
    get { return (double)GetValue(MinimumProperty); }
    set { SetValue(MinimumProperty, value); }
}

public static readonly DependencyProperty MinimumProperty =
    DependencyProperty.Register("Minimum", typeof(double), typeof(MyDependencyObject), new PropertyMetadata(default(double), MinimumChanged));

private static void MinimumChanged(DependencyObject source, DependencyPropertyChangedEventArgs args)
{
    MyDependencyObject instance = (MyDependencyObject)source;
    // TODO - implement change handling here
}

Download

Enjoy: Download Snippets.zip (5KB).

For installation instructions see here: WPF Snippets for Visual Studio.

If you have any other suggestions for snippets you'd like to see, please leave a comment.

Bindorama - Binding Craziness now for Silverlight too!

Josh Twist — Tue, 28 Jul 2009 00:21:17 GMT

A while back I posted And now for something completely crazy: Binding without WPF where I proposed a class that would allow you to use WPF's awesome binding deep inside your own code away from any visuals - awesome stuff for some complex ViewModel scenarios.

I unimaginatively entitled the class BindingObject but here's the Silverlight version and I've decided to name him: Bindorama!

Here's the code:

public class Bindorama : FrameworkElement, IDisposable
{
    private bool _suppress;
    private Action<DependencyPropertyChangedEventArgs> _onChanged;

    public Bindorama(object source, string bindingPath, Action<DependencyPropertyChangedEventArgs> onChanged)
    {
        using (SuppressNotifications())
        {
            _onChanged = onChanged;

            Binding binding = new Binding(bindingPath);
            binding.Source = source;
            BindingOperations.SetBinding(this, ValueProperty, binding);
        }
    }

    public object Value
    {
        get { return (object)GetValue(ValueProperty); }
        set { SetValue(ValueProperty, value); }
    }

    public static readonly DependencyProperty ValueProperty =
    DependencyProperty.Register("Value", typeof(object), typeof(Bindorama), new PropertyMetadata(null, ValueChangedCallback));

    private static void ValueChangedCallback(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var instance = (Bindorama)d;
        Action<DependencyPropertyChangedEventArgs> onChanged = instance._onChanged;
        if (onChanged != null && !instance._suppress)
        {
            onChanged(e);
        }
    }

    public void Dispose()
    {
        BindingOperations.SetBinding(this, ValueProperty, null);
        _onChanged = null;
    }

    public IDisposable SuppressNotifications()
    {
        return new Supresser(this);
    }

    private class Supresser : IDisposable
    {
            private Bindorama _bindingObject;

        public Supresser(Bindorama bindingObject)
        {
            _bindingObject = bindingObject;
            _bindingObject._suppress = true;
        }

        public void Dispose()
        {
            _bindingObject._suppress = false;
        }
    }
}

What are the advantages of this over just subscribing to INotifyPropertyChanged?

Weak reference based - no more leaking memory.
Can go deep on properties: "Property.That.I.Want.To.Monitor" - this is hard to do well manually
Can use indexers: "Collection[0]"

And here's how you use him:

Bindorama b = new Bindorama(objectYouWantToMonitor, "Property.You.Want.To.Monitor", DelegateToFireOnChange);

public void DelegateToFireOnChange(DependencyPropertyChangedEventArgs args)
{
    MessageBox.Show(string.Format("NewValue: {0}, OldValue: {1}",
        args.NewValue,
        args.OldValue);
}

Awesome!

Note, if the instance of Bindorama gets garbage collected then the event will stop firing (obviously). So you may need to keep a reference to it to keep it alive. Of course, this has huge advantages to help prevent memory leaks that so often occur when we start registering for events.

If you need to deterministically stop the events firing, then dispose the Bindorama (b.Dispose()). It's IDisposable so you can use it inside a using block if necessary.

Finally, I thought some extension methods might make this easier to use:

public static class BindoramaExtensions
{
    public static IDisposable Watch(this INotifyPropertyChanged source, string propertyExpression, Action<DependencyPropertyChangedEventArgs> onChanged)
    {
        return CoreWatch(source, propertyExpression, onChanged);
    }

    public static IDisposable Watch(this DependencyObject source, string propertyExpression, Action<DependencyPropertyChangedEventArgs> onChanged)
    {
        return CoreWatch(source, propertyExpression, onChanged);
    }

    private static IDisposable CoreWatch(object source, string propertyExpression, Action<DependencyPropertyChangedEventArgs> onChanged)
    {
        return new Bindorama(source, propertyExpression, onChanged);
    }
}

Which means you can now simply 'Watch' any INotifyPropertyChanged instance of DependencyObject easy peasy:

objectYouWantToMonitor.Watch("Property.You.Want.To.Monitor", args => MessageBox.Show(args.NewValue.ToString()));

Note that this returns IDisposable and he'll need to remain rooted if you want to receive change notifications (or dispose him to stop listening).

Creating a Range Slider in Silverlight (and some of the binding gotchas in SL3)

Josh Twist — Thu, 16 Jul 2009 04:12:06 GMT

Yesterday, I posted about how to Create a Range Slider in WPF using composition within a UserControl.

Today, I want to do the same in Silverlight and _try_ to use the same technique(s).

The obvious things that need to change are:

The Slider ControlTemplate
Removing the ElementName binding

I can hear you all now: "No! Josh! Silverlight 3 has ElementName binding support! You don't need to remove it! Nooooo!".

Sadly though, we can't use it the way I did in yesterday's post. Let's recap the big tip I was using:

<UserControl x:Class="UserControlFun.RangeSlider"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Name="root">
    <Slider x:Name="LowerSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=LowerValue}" />
    <Slider x:Name="UpperSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=UpperValue}" />
</UserControl>

As you can see we give the UserControl element a name. This is supported in WPF but not recommended in Silverlight. This is because in Silverlight an element can only have one name and therefore if we specify a Name where we use the control, like this:

<local:RangeSlider x:Name="overridingName" />

the internal ElementName binding will now fail (silently) because we changed the name. One solution might be to *not* rename the element where it's used but there's another problem: we can only use this control once or we'll have two elements with the same name.

This is very sad and I hope this is fixed in future releases. However, there is a workaround that seems to achieve what I want to achieve.

The trick is to use ambient binding (no ElementName) by programmatically setting the DataContext in the control's constructor:

public RangeSlider()
{
    InitializeComponent();
    this.Loaded += new RoutedEventHandler(RangeSlider_Loaded);
    LayoutRoot.DataContext = this;
}

Notice that we specifically don't set this.DataContext = this;. That would break any bindings specified on the UserControl externally. Instead, we head for the first child of our UserControl - in this case, called 'LayoutRoot'.

Here's the Xaml for the UserControl:

<UserControl x:Class="UserControlFunSL3.RangeSlider"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
    <Grid x:Name="LayoutRoot" VerticalAlignment="Top">

    

        <Border BorderThickness="0,1,0,0" BorderBrush="Black" VerticalAlignment="Center" Height="1" Margin="5,0,5,0"/>

        <Slider x:Name="LowerSlider"
            Minimum="{Binding Minimum}"
            Maximum="{Binding Maximum}"
            Value="{Binding LowerValue, Mode=TwoWay}"
            Margin="0,0,10,0"
            Template="{StaticResource sliderTemplate}"
            />

        <Slider x:Name="UpperSlider"
            Minimum="{Binding Minimum}"
            Maximum="{Binding Maximum}"
            Value="{Binding UpperValue, Mode=TwoWay}"
            Margin="10,0,0,0"
            Template="{StaticResource sliderTemplate}"
            />
    </Grid>
</UserControl>

Finally, we need our Silverlight specific Slider Template:

<Grid.Resources>
    <ControlTemplate x:Key="buttonTemplate" TargetType="RepeatButton">
    
        <Grid />
    </ControlTemplate>
    <ControlTemplate x:Key="sliderTemplate" TargetType="Slider">
        <Grid x:Name="HorizontalTemplate" Background="{TemplateBinding Background}">
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="Auto"/>
                <ColumnDefinition Width="Auto"/>
                <ColumnDefinition Width="*"/>
            </Grid.ColumnDefinitions>
            <RepeatButton Template="{StaticResource buttonTemplate}" IsTabStop="False" IsEnabled="False" x:Name="HorizontalTrackLargeChangeDecreaseRepeatButton" Grid.Column="0"/>
            <Thumb IsTabStop="True" Height="18" x:Name="HorizontalThumb" Width="11" Grid.Column="1">
                <Thumb.Template>
                    <ControlTemplate TargetType="Thumb">
                        <Rectangle Fill="Red"
                            Stroke="Black"
                            StrokeThickness="1" />
                    </ControlTemplate>
                </Thumb.Template>
            </Thumb>
            <RepeatButton Template="{StaticResource buttonTemplate}" IsTabStop="False" IsEnabled="False" x:Name="HorizontalTrackLargeChangeIncreaseRepeatButton" Grid.Column="2"/>
        </Grid>
    </ControlTemplate>

</Grid.Resources>

And we're done. Almost everything else is the same as our WPF control. Why not have a play with the control right here:

Or, get the source here: Download Source (7KB). Usual disclaimers for demoware apply.

Creating a Range Slider in WPF (and other cool tips and tricks for UserControls)

Josh Twist — Wed, 15 Jul 2009 14:34:52 GMT

I've had to create a RangeSlider (where you can select a range within a range, not just a value) several times now and there's a couple of neat tricks I use to compose such controls that I thought I'd share with you.

The idea is simple, the control should look like a slider but with two 'thumbs':

The way I chose to tackle this was, as always, to leverage existing controls wherever possible. Composition is king in WPF and UserControls provide a very lightweight, cheap angle of attack here.

I decided to have a UserControl composed, primarily, of two Sliders stack on top of each other.

Logically, the RangeSlider would have four properties:

Minimum (double)
LowerValue (double)
UpperValue (double)
Maximum (double)

So the first thing to do is add these as dependency properties to our new UserControl (called RangeSlider):

public double Minimum
{
    get { return (double)GetValue(MinimumProperty); }
    set { SetValue(MinimumProperty, value); }
}

public static readonly DependencyProperty MinimumProperty =
    DependencyProperty.Register("Minimum", typeof(double), typeof(RangeSlider), new UIPropertyMetadata(0d));

public double LowerValue
{
    get { return (double)GetValue(LowerValueProperty); }
    set { SetValue(LowerValueProperty, value); }
}

public static readonly DependencyProperty LowerValueProperty =
    DependencyProperty.Register("LowerValue", typeof(double), typeof(RangeSlider), new UIPropertyMetadata(0d));

public double UpperValue
{
    get { return (double)GetValue(UpperValueProperty); }
    set { SetValue(UpperValueProperty, value); }
}

public static readonly DependencyProperty UpperValueProperty =
    DependencyProperty.Register("UpperValue", typeof(double), typeof(RangeSlider), new UIPropertyMetadata(0d));

public double Maximum
{
    get { return (double)GetValue(MaximumProperty); }
    set { SetValue(MaximumProperty, value); }
}

public static readonly DependencyProperty MaximumProperty =
    DependencyProperty.Register("Maximum", typeof(double), typeof(RangeSlider), new UIPropertyMetadata(1d));

Properties Done.

Big trick/tip - using binding to get control data into your composition

I now need to get these properties into the controls within my UserControl. I use ElementName binding to this and it looks like this:

<UserControl x:Class="UserControlFun.RangeSlider"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Name="root">
    <Slider x:Name="LowerSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=LowerValue}" />
    <Slider x:Name="UpperSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=UpperValue}" />

</UserControl>

Notice how we set a name on the UserControl which allows us to bind to him and access all his properties - inluding our juicy new ones. Even, better, because the Bindings are two way any updates propagate between the UserControl and the composed controls. Awesome. Functionally, we already have most of our control!

Some rules need applying, e.g. the UpperValue should always be greater than or equal to the LowerValue and I'd even like one slider to drag the other along if it bumps into it.

However, the most pressing problem at the moment is the fact that my control looks like this:

Which is clearly wrong and, worse still, I can't click through to the LowerSlider control.

No problem - just time to re-template! Remembering how templates work and need to be composed for each control is a nightmare.

little tip - steal templates from Blend

Another trick I use is to get Expression Blend to reveal the internal ControlTemplates of controls. Just drag a Slider onto the design surface, right click, choose 'Edit Control Templates' > 'Edit a copy' and you're away. You can now head off to Xaml view to get a good look at the ControlTemplate.

Be warned, some of the ControlTemplates in WPF are extremely complicated. Don't be put off though - in our case the required template is very simple. To keep the post short, I'm going to go for a very simple looking slider, here's the ControlTemplate for the individual sliders:

<ControlTemplate x:Key="simpleSlider" TargetType="{x:Type Slider}">
    <Border SnapsToDevicePixels="true"
            BorderBrush="{TemplateBinding BorderBrush}"
            BorderThickness="{TemplateBinding BorderThickness}">
        <Grid>
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto"/>
                <RowDefinition Height="Auto" MinHeight="{TemplateBinding MinHeight}"/>
                <RowDefinition Height="Auto"/>
            </Grid.RowDefinitions>

            <Rectangle x:Name="PART_SelectionRange"/>

            <Track x:Name="PART_Track" Grid.Row="1">
                <Track.Thumb>
                    <Thumb x:Name="Thumb">
                        <Thumb.Template>
                            <ControlTemplate TargetType="Thumb">
                                <Rectangle Fill="Red"
                                    Stroke="Black"
                                    StrokeThickness="1"
                                    Width="10"
                                    Height="18"
                                    SnapsToDevicePixels="True"/>
                            </ControlTemplate>
                        </Thumb.Template>
                    </Thumb>
                </Track.Thumb>
            </Track>
        </Grid>
    </Border>
</ControlTemplate>

And here's the two Sliders (and a border to create the line that represents the range):

<Grid VerticalAlignment="Top">
    <Border BorderThickness="0,1,0,0"
        BorderBrush="Black"
        VerticalAlignment="Center"
        Height="1"
        Margin="5,0,5,0"/>

    <Slider x:Name="LowerSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=LowerValue}"
        Template="{StaticResource simpleSlider}"
        Margin="0,0,10,0"
    />
    <Slider x:Name="UpperSlider"
        Minimum="{Binding ElementName=root, Path=Minimum}"
        Maximum="{Binding ElementName=root, Path=Maximum}"
        Value="{Binding ElementName=root, Path=UpperValue}"
        Template="{StaticResource simpleSlider}"
        Margin="10,0,0,0"
    />
</Grid>

The Margins stop the two thumbs overlapping (so it looks like one literally pushes the other along).

Finally, I had to add some code-behind (boo!) to monitor for changes in the sliders. I only want these hooked up after the control has loaded so here's the UserControl's constructor and some subsequent delegates:

public RangeSlider()
{
    InitializeComponent();
    this.Loaded += RangeSlider_Loaded;
}

void RangeSlider_Loaded(object sender, RoutedEventArgs e)
{
    LowerSlider.ValueChanged += LowerSlider_ValueChanged;
    UpperSlider.ValueChanged += UpperSlider_ValueChanged;
}

private void LowerSlider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
{
    UpperSlider.Value = Math.Max(UpperSlider.Value, LowerSlider.Value);
}

private void UpperSlider_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
{
    LowerSlider.Value = Math.Min(UpperSlider.Value, LowerSlider.Value);
}

Which altogether looks like (with some added bound textboxes to show the values):

There's plenty that I haven't accounted for in the control so far:

Vertical Orientation
Visualising Disabled State, Focussed State etc
No doubt much, much, more...

Nonetheless it works reasonably well as a starter and was very easy to implement. Get the source code here: Download Source (9KB).

Enjoy - usual demoware disclaimers apply.

UPDATE Why not check out the Silverlight example in my follow up post.

Animating when Data Changes - Part II

Josh Twist — Mon, 13 Jul 2009 02:14:25 GMT

In Animating when data changes I talked about some of the difficulties of using animation with the MVVM pattern and how to overcome them.

Having discussed this post with some people they felt I targetted a fairly edge scenario, that is - content changing. What if a control is bound to a property of the view model and I want the control to animate when the value changes?

Fair enough. The important note is that the concept is the same. In my opinion, this animation is not a concern of the ViewModel and so we need to extract it from that space. As with most problems in software development (save for code simplicity and performance) we just need another layer of indirection. In this case we'll use a UserControl.

Imagine we have a Value property on a ViewModel and it is two-way bound to a Slider and also bound to a ProgressBar. However, we want the ProgressBar to animate smoothly when the value is changed.

Our ViewModel might look something like this:

public class SimpleViewModel : INotifyPropertyChanged
{
    private double _value;

    public double Value
    {
        get { return _value; }
        set
        {
            _value = value;
            OnPropertyChanged("Value");
        }
    }

    // snipped INPC implementation for brevity
}

Easy. Our xaml might look something like this:

<StackPanel>
    <Slider Value="{Binding Value, Mode=TwoWay}" Maximum="10"/>
    <ProgressBar Value="{Binding Value}" Height="20" Maximum="10"/>
</StackPanel>

The two controls are now bound together via our ViewModel. Let's imagine that there are multiple ways of updating the Value property (not just via the slider) and we want the ProgressBar to react in a nice animated smooth and slooooow way.

This is a pattern I use a lot in both WPF and Silverlight to implement animation. In this case the example is Silverlight but the code for WPF is almost identical.

First, I create a new UserControl to host the ProgressBar and add a Value Dependency Property.

public partial class AnimatedProgressBar : UserControl
{
    public AnimatedProgressBar()
    {
        InitializeComponent();
    }

    public double Value
    {
        get { return (double)GetValue(ValueProperty); }
        set { SetValue(ValueProperty, value); }
    }

    public static readonly DependencyProperty ValueProperty =
    DependencyProperty.Register("Value", typeof(double), typeof(AnimatedProgressBar), new PropertyMetadata(0d, ValueChanged));
}

Notice that I registered a DependencyPropertyChangedEventHandler called ValueChanged - more on him later.

And the Xaml for my user control looks like this:

<UserControl x:Class="AnimatingOnDataChangePartII.AnimatedProgressBar"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<ProgressBar x:Name="progress" Maximum="10" />
</UserControl>

Now, that ValueChanged handler:

public static void ValueChanged(DependencyObject sender, DependencyPropertyChangedEventArgs args)
{
    // Get out of a static and into the instance ASAP.
    AnimatedProgressBar control = (AnimatedProgressBar)sender;
    control.ValueChanged();
}

private void ValueChanged()
{
    DoubleAnimation animation = new DoubleAnimation();;
    animation.To = this.Value;
    animation.Duration = new Duration(TimeSpan.FromSeconds(2));
    Storyboard.SetTarget(animation, progress);
    Storyboard.SetTargetProperty(animation, new PropertyPath(ProgressBar.ValueProperty));
    Storyboard sb = new Storyboard();
    sb.Children.Add(animation);
    sb.Begin();
}

So, we needed a little code behind but at least it's in the right place. The animation is part of the visual implementation and nothing to do with our 'canonical ViewModel'. Even better, our root Xaml still makes sense from a binding/ViewModel perspective - thanks to our use of a Dependency Property:

<StackPanel>
<Slider Value="{Binding Value, Mode=TwoWay}" Maximum="10"/>
<local:AnimatedProgressBar Value="{Binding Value}" Height="20" />
</StackPanel>

Here's the sample for you to play with:

And here's the source: Download Source (24KB) - usual demoware disclaimers apply.

Scripting Wake On Lan

Josh Twist — Tue, 30 Jun 2009 02:13:20 GMT

I mentioned recently about wantint to be able to wake up various machines in my house remotely. My colleague introduced me to AutoExit for Windows Home Server which works a treat. However, logging onto the Windows Home Server console is a bit, well, slow.

So, now that I do quite a bit of remote desktop to my development machine I want a quicker, easier way of waking it up.

The solution was a .bat file that uses the very handy WoLCmd command line executable from www.depicus.com. There's also a GUI, an ASP and a COM version. Very handy.

They even provide the .NET source to Wake-on-Lan yourself here.

Anyway, I simply botched a bat file together next to my downloaded copy of WolCmd and created a shortcut to the batch file on my desktop. Here's the script:

echo on
wolcmd.exe <MAC-ADDRESS-HERE> <IP-ADDRESS-HERE> 255.255.255.0 7
pause

Easy.

Building an Atom-based media PC for the house

Josh Twist — Sun, 28 Jun 2009 10:26:50 GMT

I believe there's a rule that goes along the lines of:

If you have a blog, and you build a PC, you must write a review/walkthrough of the process and post it; with lots of pictures. This is mandatory and failure to comply is punishable by nail-varnishing of the eyeballs.

Now, not wanting to have my eyeballs nail varnished, I thought I better follow suit. Weirdly, this is the first time I've ever built a PC from scratch. I've pulled existing PCs to pieces and failed to put them back together hundreds of times but never started from fresh bits like this. It was exciting.

The requirements/considerations for my new PC are as follows:

The primary purpose would be as a media PC to go with the TV in our second living room (so I can watch Grand Prix without annoying the wife)
I'd like it to house the Blu-Ray drive I harvested from my server
It needs to be small enough to fit on a shelf
The secondary purpose would be as a head to Remote-Desktop in to my development PC when I fancied doing a bit of dev in another room
The room can get bloody hot on a hot day, so cooling might be an issue
It needs to be fairly quiet, though I'm not as fussy about most on this - background noise tends not to bother me too much
Now that I've gone Power Nuts, I'd like it not to consume too much power either

The natural choice at the moment for any low-power small-form-factor PC is the Intel Atom of netbook/nettop fame. However, traditionally they've been underpowered in the graphics department for use as a media PC. Until the nVidia ION came along.

I decided to opt for the Zotac IONITX A-B N330 whose highlights include:

dual-core Atom processor
nVidia ION graphics
Includes external 90W power supply
bundled WiFi (occupying the only PCI-E x1 slot)

You can read a good review of this board here on silentpcreview.com.

The dual core version comes with an optional fan where according to the documentation "If your system working at a torrid room,you can append a FAN to the heatsink (sic)". That's one description for the conservatory on a very hot day with the windows closed. And thus, I decided to attach the fan. It's a little noisier than I'd like and there's no way to slow it down. I suspect I may replace this at some point in the near future with a quieter model but for now, it keeps the heatsink incredibly cool (before the fan was attached, the heatsink was too hot to touch).

Anyway, I won't bore you with all the details of the build but here are the mandatory pictures of the build.

The cheesiest RAM in the world (above).

It lives! (above)

The fan, mounted by screwing into the heatsink - quite bizarre as there aren't any 'holes' (above)

The case is an A+ Cupid-3 which was particularly suitable as it was mini-ITX and offered a full-size 5.25" drive bay to host the huuuge Blu-Ray drive. The case actually came with a 200W PSU but I removed that as the motherboard has its own external PSU and can happily power three SATA devices inside the case (I only needed two) - so if you need a 200W PSU, give me a shout :).

The case is also pretty attractive and was very easy to work with. There's still room for an extra 3.5" HDD too, which is good.

The monitor

The best part of my new computing experience has to be the 26" Samsung Syncmaster LCD TV/Monitor I picked up. 26" isn't that largest TV screen in the world but it's a big monitor. And it's a thing of beauty - I'm already addicted to using it over all my other monitors. The quality of the picture is amazing. The sound is a little weak but I'll be routing that over a hi-fi so no issue there for me.

The finished package

Here's the links to the bits I bought from the stores I used:

A+ Cupid-3 Mini ITX Case (inc PSU)
4GB (2x2GB) Super*Talent DDR2 800 RAM
Zotac ION ATOM N330 Dual Core motherboard
Samsung T260HD LCD/TV Monitor

Silverlight Validation and ViewModel

Josh Twist — Fri, 26 Jun 2009 01:54:22 GMT

Silverlight 3 brings some improvements to Validation for users of the MVVM (Model-View-ViewModel, or just ViewModel) pattern. Specifically, most controls now have a Visual State for a control that has generated binding validation errors.

The default InvalidFocused state looks pretty cool:

And, with Silverlight's Binding supporting ValidatesOnExceptions (publishes a validation error if a setter throws an exception) and NotifyOnValidationError (sends a BindingValidationError event up tree) it's easy to use this with the ViewModel pattern.

Filling in the details

Most examples out there demonstrate how to use these capabilities so I won't go into the gritty details. However, I want to try and take that knowledge and try to apply it in a slightly more reusable way. There are two key problems I'm trying to solve.

The first problem... dealing with _your_ exceptions

The first is that it becomes difficult for us to tell if our ViewModel is in a valid state or not. Take the following very simple ViewModel:

public class MyViewModel : INotifyPropertyChanged
{
    private int _age = 1;

    public int Age
    {
        get { return _age; }
        set
        {
            if (value <= 0)
            {
                throw new Exception("Age must be greater than 0");
            }
            _age = value;
            OnPropertyChanged("Age");
        }
    }

    public void Save()
    {
        // TODO
    }

    // NotifyPropertyChanged implementation snipped for brevity

And the Xaml with the binding:

<TextBox Text="{Binding Path=Age, Mode=TwoWay, NotifyOnValidationError=True, ValidatesOnExceptions=True}" />

As you can see, this ViewModel has been designed to leverage the ValidatesOnExceptions feature of Silverlight's Binding, raising an Exception if somebody tries to set the Age property to 0 or less (the image above shows how this would look).

The problem comes when we try to 'save' the state of the ViewModel. How can we tell if it's valid or not? Following a Validation Failure we throw an exception and don't set the value of the _age property. Therefore the ViewModel itself is still actually valid.

I can think of a myriad of solutions to this ranging from leveraging some of the features in existing validation frameworks like P&P's Validation Application Block (which is a good idea in any case) to simply allowing the Age property to be set _before_ throwing the Exception. Now the object will be in an 'invalid' state and we can prevent a 'save' taking place.

We're half way there...

The second problem... dealing with binding failures

However, the solution above only works if the TwoWay binding succeeds. What if the user enters 'hello' into the Age field?

That's handy but the update never made it to the ViewModel so, as far as it knows, it's still in a valid state so we can't prevent the save taking place.

A solution?

Since the ViewModel is all about the state of the view, it seems fair that it should be aware of *all* binding and validation failures like this. After all, it might want to host that information so another part of the View can display all the current failures. A validation summary if you will - but in a ViewModel way.

Of course, being a no-code-behind zealot. I'd like to achieve this with as little code-behind as possible in the view. Step forward Attached Behaviors.

My idea is to have an attached property called ValidationScope.Errors that can be attached to any FrameworkElement. The property would be of type IList and would handle the BindingValidationError for the element to which it's attached (creating a ValidationScope, effectively).

Then all we need to do is bind this attached property to an ObservableCollection on our ViewModel.

Here's the Attached Behavior/Property:

public class ValidationScope
{
    public static IList<ValidationError> GetErrors(DependencyObject obj)
    {
        return (IList<ValidationError>)obj.GetValue(ErrorsProperty);
    }

    public static void SetErrors(DependencyObject obj, IList<ValidationError> value)
    {
        obj.SetValue(ErrorsProperty, value);
    }

    // Using a DependencyProperty as the backing store for Errors. This enables animation, styling, binding, etc...
    public static readonly DependencyProperty ErrorsProperty =
        DependencyProperty.RegisterAttached("Errors", typeof(IList<ValidationError>), typeof(ValidationScope),
        new PropertyMetadata(null, ErrorsChanged));

    public static void ErrorsChanged(DependencyObject obj, DependencyPropertyChangedEventArgs args)
    {
        FrameworkElement element = (FrameworkElement)obj;
        element.BindingValidationError += delegate(object sender, ValidationErrorEventArgs e)
            {
                if (e.Action == ValidationErrorEventAction.Added)
                {
                    GetErrors(obj).Add(e.Error);
                }
                else
                {
                    GetErrors(obj).Remove(e.Error);
                }
            };
    }
}

And here it is being used by our Xaml:

<Grid x:Name="LayoutRoot" Background="White" local:ValidationScope.Errors="{Binding Errors}">
    <StackPanel>
        <TextBlock Text="Name:" />
        <TextBox Text="{Binding Path=Name, Mode=TwoWay, NotifyOnValidationError=True, ValidatesOnExceptions=True}" />
        <TextBlock Text="Age:" />
        <TextBox Text="{Binding Path=Age, Mode=TwoWay, NotifyOnValidationError=True, ValidatesOnExceptions=True}" />
        <Button Content="Save" Click="Button_Click" />
    </StackPanel>
</Grid>

Clearly, we need an 'Errors' property on our ViewModel:

private readonly ObservableCollection<ValidationError> _errors = new ObservableCollection<ValidationError>();

public ObservableCollection<ValidationError> Errors
{
    get { return _errors; }
}

public bool IsViewStateValid()
{
    return Errors.Count == 0;
}

Notice that we can easily add an IsViewStateValid method too that simply sniffs the Errors collection.

And our save method?

pbulic void Save()
{
    if (!this.IsViewStateValid())
    {
        _dialogService.DisplayValidationDialog(Errors);
    }
    else
    {
        // TODO - SaveData
    }
}

In my example, I used one of Silverlight's new Child Windows to display my error dialog - passing the Errors collection so it could be used as a ViewModel for the dialog:

There are other challenges ahead though.. what happens if an object's state can be rendered invalid by a combination of properties? For example, maiden name should be blank if sex == male? In that case it becomes difficult to use the practice of throwing exceptions in setters as you start a chicken/egg race. For these reasons, I'd look at patterns like the Validation Application Block and lean on their concepts when implementing a full LOB validation approach.

Having said all that - before doing any of this you should definitely check out Silverlight 3's DataForm control. You could do much worse than spend 25 minutes watching Mike Taulty's excellent screencast: DataForm control. In particular, pay attention to some of the Validation support including the CustomValidation attribute.

Finally, if you'd like the code from the example I worked up before, you can download it here. Usual disclaimers apply - this is just demoware.