Introduction

I’m currently using TinyIoC in my first forays into MonoTouch development, and my initialisation code was throwing a resolution error on starup:

var container = TinyIoCContainer.Current();
var mainView = new MainView();
container.Register<IViewManager>(mainView);
container.Register<IView, MainView>(mainView, "MainView");
container.Register<IView, SplashView>("SplashView").UsingConstructor(() => new SplashView());
container.Resolve<IView>("MainView");
container.Register<IStateManager, StateManager>();
// Code was blowing up here..
var stateManager = container.Resolve<IStateManager>();
stateManager.Init();

The Exception that was given was that IStateManager could not be resolved, which was odd given that the StateManager was registered against IStateManager, and everything in its constructor was also registered:

public StateManager(IViewManager viewManager, Func<string, IView> viewFactory)

To The Debugger.. Right?!

So at this point your immediate reaction may be to fire up the debugger, trace into the code and start hacking around, debugging and hacking around some more until it works. Sure, that’s an approach, and one I’m sure we’ve all used in the past; but as I was pretty sure the issue was in TinyIoC itself I took a slightly different tack.

To The Test Runner!

With the approach above I would have to build and run my app every time I wanted to check if my “fix” had actually worked – and even if it had, how would I know it hadn’t broken something else? The solution is quite simple – recreate the conditions of the bug in a unit test, using stubs/mocks to replace your real classes, and make sure it fails in the same way:

[TestMethod]
public void Dependency_Hierarchy_With_Named_Factories_Resolves_All_Correctly()
{
    var container = UtilityMethods.GetContainer();
    var mainView = new MainView();
    container.Register<IViewManager>(mainView);
    container.Register<IView, MainView>(mainView, "MainView");
    container.Register<IView, SplashView>("SplashView").UsingConstructor(() => new SplashView());
    container.Resolve<IView>("MainView");
    container.Register<IStateManager, StateManager>();
    var stateManager = container.Resolve<IStateManager>();
    stateManager.Init();

    Assert.IsInstanceOfType(mainView.LoadedView, typeof(SplashView));
}

I’ve added an Assert to show what behaviour I think it *should* have. It’s a pretty horrible looking test, but it accurately represents what my failing code was doing, and the test fails as I expected it to. Now I can attach the debugger and find out what’s going on, safe in the knowledge I have a fast executing test available to verify my fix, and the rest of my test suite there to ensure I haven’t broken anything else.

After a very brief investigation it turned out that there was a bug in registration when *just* an Interface type was registered with an concrete instance (the IViewManager registration above). The “InstanceFactory” it was using hadn’t set the “AssumeResolves” flag, so TinyIoC was actually trying to find a valid constructor for IViewManager – which obviously wasn’t going to succeed. It’s a scenario I probably should have factored into my Unit Tests, but hey, nobody is perfect

Conclusion

This post is aimed at covering two points:

1. Test aren’t just for TDD. If you find a bug, isolate it with a test and you have a quick and easy way to verify a fix, and verify you haven’t broken anything else.
2. Code Coverage isn’t everything. Apart from a few “defensive coding” null checks, the core of TinyIoC has pretty much 100% code coverage with its tests, but it didn’t help me with this issue. Although the code path was covered, the exact input (Interface type, concrete instance) wasn’t in my unit tests, so don’t assume 100% code coverage means 0 bugs in the code, there may well be a scenario you missed!

Technorati Tags: csharp, debugging, MonoTouch, testing, TinyIoC, unit testing

Whenever I start a new “pet” project I usually *want* to use IoC, but I don’t really want the hassle of taking a dependency on a container, or adding another binary to my project. Usually this leaves me using “poor man’s IoC”, whereby I define dependencies in my constructors, but I pass them in manually or construct them using constructor chaining.

I’ve thought for some time that it would be useful to put together a container that fits the bill for that scenario, but also attempts to “lower the barrier of entry” for developers that are new to IoC, and may be scared off by the “big boys”. A couple of weeks ago @DotNetWill posted his simplified container, and that gave me the kick up the backside I needed to create my own

Introducing TinyIoC

Now you might ask “do we really need *another* IoC container?” – and it’s a reasonable question. We already have Unity, Ninject, StructureMap, AutoFac.. the list goes on. TinyIoC makes no attempt to go “head to head” with any of these other containers, instead TinyIoC has been designed to fulfil a single key requirement:

To lower the “level of entry” for using an IoC container; both for small projects, and developers who are new to IoC.

To that end, TinyIoC attempts to stick the following core principals:

• Simplified Inclusion. No assembly to reference, no binary to worry about, just a single cs file you can include in your project and you’re good to go. It also works on Mono, and on MonoTouch for the iPhone / iPad.
• Simplified Setup. With auto-resolving of concrete types and an “auto registration” option for interfaces, setup is a piece of cake. It can be reduced to 0 lines for concrete types, or 1 line if you have any interface dependencies.
• Simple, “Fluent” API. Just because it’s Tiny, doesn’t mean it has no features. A simple “fluent” API gives you access to the more advanced features, like specifying singleton/multi-instance, strong or weak references or forcing a particular constructor.

The following snippet gives an example of the simplified setup:

// TinyIoC provides a lazyily constructed singleton
// version of itself if you want to use it.
var container = TinyIoCContainer.Current;

// By default we can resolve concrete types without
// registration
var instance = container.Resolve<MyConcreteType>();

// We can automatically register all concrete types
// and interfaces with a single call.
container.AutoRegister();
var implementation = container.Resolve<IMyInterface>();

So Where Now?

If you want to grab the source, read the tests, or take a look at some more complex examples of the API, wander on over to the homepage on bitbucket. I’m happy to take comments and suggestions – just grab me on Twitter or ping me an email from the contact form.

Over the next few weeks I will be posting a series of “beginners” articles on the hows and whys of IoC. I will be using TinyIoC specifically, but the majority of concepts and content can equally apply to other containers. I may even do a “File, New” screencast to show how “un-scary” this stuff is, and how it doesn’t really add any extra development effort,

Technorati Tags: csharp, dependency injection, di, inversion of control, ioc, TinyIoC

Let me start with a disclaimer. I’ve only been using Mercurial for 2 days so my nomenclature may be completely wide of the mark. Hopefully this post will help other hgnewbies with what is probably a common requirement.

Introduction

I keep all of my pet projects in my own Subversion repository but I’ve recently decided to give this distributed version control shenanigans a whirl. I ummed and arred about Git or Mercurial, but in the end I plumped for Mercurial, with a bitbucket account, as it seems to have more ubiquitous support. I’m about to release a project I’ve been working on for the last week or so and thought it would be nice to release it via bitbucket – complete with the version history I’d build up in Subversion.

Turns out, it’s really rather easy!

I’m Converted!

I’m assuming at this point you have the commandline version of Mercurial (hg) installed and working. If you don’t then you should probably go and do that first I’ve also assumed you’ve already created a mercurial repository (bitbucket or elsewhere) called “myproject”.

In my scenario I was converting a single project with no trunk, branch or tag directories. The convert command is capable of handling much more advanced scenarios – take a look at the documentation for more infomation.

First things first you need to edit your Mercurial settings (.hgrc for *nix, Mercurial.ini in your user dir for Windows) and add the following lines:

[extensions]
hgext.convert=

This will add the “convert” command extension to our client. Next up we clone our repository and use the new convert command to add the SVN changesets into it:

hg clone https://bitbucket.org/myuser/myproject

hg convert http://mysvn.server.com/svn/myproject/ myproject

The convert command will now start counting down the revisions and adding each one to our local hg repository. This may well take some time

Potential gotcha: it appears that the convert extension doesn’t work properly with Subversion repositories over http that require authentication. If you get multiple “http authorization required” messages and prompts for your username/password then you have a problem. The only solution I found was to temporarily disable authentication while I did the conversion

Once the conversion had finished we push our changes back:

cd myproject

hg push

Now at this point for me the push worked fine but my local repository had no files in it – despite insisting it was up to date. This may be my lack of knowledge on Mercurial, or it might be a bug, but deleting the myproject directory locally and cloning the remote repo again sorted things out.

Conclusion

All in all a pretty trivial task, albeit one that takes a while with a large repository. The only big issue is the authentication one I mention above – this may well be a showstopper for you if you can’t control the ACL on your Subversion repository.

Technorati Tags: convert, hg, history, Mercurial, subversion, svn

Following on from my previous post about a “Thread Safe” Dictionary, and the subsequent comment from Rajeesh, made me think that perhaps a general post on “thread safety” was in order.

Stop With the Quotes Already!

The astute amongst you may notice I always try and put the phrase “thread safe” in quotes; and there is a good reason for that! “Thread safe” is a pretty horrible term (although I can’t think of a better one) that doesn’t really give enough detail for what exactly we mean when we express that a class is “thread safe”. As far as I’m concerned, my “library” classes are thread safe if:

“All public static and instance methods and properties on the class are safe to be called concurrently from multiple threads.”

What this certainly does *not* mean is:

“You do not have to consider thread safety or concurrency issues in your own code that uses this class.”

So in the instance of our dictionary if you get/set a value and then in subsequent lines of code you *assume that the value you got or set hasn’t changed* then you have a concurrency issue in *your* code and you will *need to address it, likely using the same synchronisation primitives we used internally in our SafeDictionary class.*

Some Examples

As an example we can take similar code to the snippet that Rajeesh posted:

// Check the item exists and process
// if it does
if (mySafeDictionary["Testing"] != null)
{
    // Process element
    ProcessElement(mySafeDictionary["Testing"]);
}

Although each of those calls to the SafeDictionary are themselves threadsafe, we are making an assumption in *our code* that those value won’t change between the “if” statement and our call to ProcessElement. This particular scenario is one reason why we should always try to use TryGetValue, rather than the “if it exists do this with it” approach above. To this end we should probably alter our SafeDictionary to explicitly deny gets:

public class SafeDictionary<TKey, TValue>
{
    private readonly object _Padlock = new object();
    private readonly Dictionary<TKey, TValue> _Dictionary = new Dictionary<TKey, TValue>();

    public TValue this[TKey key]
    {
        set
        {
            lock (_Padlock)
            {
                _Dictionary[key] = value;
            }
        }
    }

    public bool TryGetValue(TKey key, out TValue value)
    {
        lock (_Padlock)
        {
            return _Dictionary.TryGetValue(key, out value);
        }
    }
}

If you now try and access a member using the array syntax, rather than through TryGetValue you will get a compile time error like:

The property or indexer ‘Variabler.this[string]‘ cannot be used in this context because it lacks the get accessor.

From that simple example you may think that TryGetValue solves all our problems; but unfortunately it still isn’t able to save your from yourself! To reiterate what I said earlier, you need to consider concurrency yourself if you *assume that the value you got or set hasn’t changed*. Assuming we expand our SafeDictionary to include all of the options that the normal Dictionary supports, take the following horribly contrived example:

public List<String> GetKeysToProcess()
{
    object myObject;
    List<String> keysToProcess = new List<String>();

    // Check to see if the type is valid for
    // processing
    foreach (var currentKey in myDictionary.Keys)
    {
        if (myDictionary.TryGetValue(currentKey, out myObject))
        {
            if (myObject.GetType() == typeof(ProcessorClass))
                keysToProcess.Add(currentKey);
        }
    }

    return keysToProcess;
}

Now there’s a chance that a key might have been removed between the start of the foreach and us actually using it; but as we use TryGetValue that doesn’t matter – the value just won’t resolve. The key here (pardon the pun) is that we are building and returning a list that *makes assumptions about the contents of the dictionary*. Even if in our consuming code we stick to TryGetValue to handle items being deleted, there’s nothing in this example preventing another thread changing any of the items to be a different type – effectively rendering our List of “Keys to process” completely invalid.

Conclusion

The examples above are very contrived, and I’d hope nobody would ever write those exact pieces of code; but hopefully it illustrates the point that *just because you are working with a “Thread safe” object doesn’t mean you can ignore thread safety concerns in your own code*.

Technorati Tags: concurrency, concurrentdictionary, csharp, dictionary, locks

Introduction

A pet project I’m currently working on requires the use of an internal Dictionary to store “registered” data, which is a pretty common requirement. For this particular project I’d like to at least *attempt* to make it “thread safe” on .NET 3.5, with an eye to moving it to the ConcurrentDictionary in .NET 4 which promises not only thread safety, but more granular locking to increase multi-threaded performance.

A simple enough task, but one that I’ve seen many people make mistakes implementing.

Just Locking Writes?

It’s obvious we need to do some kind of syncronisation primitive around our writes, but first impressions might make you think that read should be ok – especially if we stick to the preferred TryGetValue pattern instead of “if it exists then get the value”:

object myValue;

// This is obviously not thread safe.
// Something else can alter the collection
// between ContainsKey and reading the
// value.
if (dictionary.ContainsKey("Testing"))
{     myValue = dictionary["Testing"];
}

// Using TryGetValue looks safe though?
// Doesn't it?!
if (!dictionary.TryGetValue("Testing", out myValue))     throw new KeyNotFoundException();

Unfortunately if we fire up Reflector, and take a look at how TryGetValue is implemented, it’s pretty obvious it has exactly the same concurrency problem as the first method above:

public bool TryGetValue(TKey key, out TValue value)
{
    int index = this.FindEntry(key);
    if (index >= 0)
    {
        value = this.entries[index].value;
        return true;
    }
    value = default(TValue);
    return false;
}

Ok, So I Will Lock Reads and Writes?

The next obvious approach would be to find everywhere in our code where we access the Dictionary, for either reading or writing, and use a syncronisation primitive, such as lock, to ensure we’re only accessing it from a single thread at any one time:

private readonly object padlock = new object();
private readonly Dictionary<string, object> dictionary = new Dictionary<string, object>();

private void Test()
{
    object myValue;

    // Now we lock before we do anything
    lock (padlock)
    {
        if (dictionary.ContainsKey("Testing"))
        {
            myValue = dictionary["Testing"];
        }
    }

    lock (padlock)
    {
        if (!dictionary.TryGetValue("Testing", out myValue))
            throw new KeyNotFoundException();
    }
}

Simple enough, but you’re relying on locking around every access, which is not only ugly, but also potentially prone to errors if you miss one. Also, once we move our code to .NET 4, and the new ConcurrentDictionary, we will have to go through the code and remove each lock in turn – pretty laborious!

Composition, Composition, Composition!

In this approach we wrap our nasty non-thread safe dictionary in our own class, expose the methods we want to use, and take any locks accordingly. This class only implements “array” access and TryGetValue, but is sufficient to show the approach:

public class SafeDictionary<TKey, TValue>
{
    private readonly object _Padlock = new object();
    private readonly Dictionary<TKey, TValue> _Dictionary = new Dictionary<TKey, TValue>();

    public TValue this[TKey key]
    {
        get
        {
            lock (_Padlock)
            {
                return _Dictionary[key];
            }
        }
        set
        {
            lock (_Padlock)
            {
                _Dictionary[key] = value;
            }
        }
    }

    public bool TryGetValue(TKey key, out TValue value)
    {
        lock (_Padlock)
        {
            return _Dictionary.TryGetValue(key, out value);
        }
    }
}

As we prevent any direct access to the Dictionary, and use our lock internally whenever we need to access it, we can now use our SafeDictionary in code without worrying about concurrency issues – both for reading and for writing!

To .Net 4 ?

As I mentioned earlier .Net 4 will be shipping with several “thread safe” collections, including a dictionary, in the new System.Collections.Concurrent namespace. As we have our own SafeDictionary implementation we have a few options here:

• We could go through our code and replace all references to SafeDictionary with ConcurrentDictionary. We don’t have any locks in our main code so we could do this with a direct replacement.
• We could alter our SafeDictionary to use a ConcurrentDictionary internally, and remove all of our internal locks.
• If we don’t mind exposing extra methods we can remove all of the implementation from SafeDictionary and just derive it from ConcurrentDictionary:

public class SafeDictionary<Tkey, TValue> : ConcurrentDictionary<Tkey, TValue>
{
}

Conclusion

Quite a long blog post for quite a simple issue, but even simple concurrency can be the source of mistakes and headaches. Once .NET 4 arrives with its concurrent collections, parallel extensions and parallel debugging options hopefully at least *some* of this headache will go away.

Technorati Tags: concurrency, concurrentdictionary, csharp, dictionary, locks

Introduction

Hotwire is a project I started some time ago but never completed. It was designed to be a “quick launch” utility for remote controlling machines using the excellent LogMeIn service. While the better half was “enjoying” the Boxing Day sales I took it upon myself to finish the project. And by finish, I obviously mean a complete rewrite

What does it do?

I’ve used LogMeIn for quite a while now, and it’s an excellent service, but 99% of the time I just want to get straight to the desktop of the machine I’m connecting to and Hotwire is designed to let me do just that.

The application itself is written using WPF and consists of two parts; the launcher, which sits in the task tray, and the main application. The launcher provides machine configuration and quick launch options for connecting to remote machines. The main application is just a single window (containing a WPF WebBrowser control) that connects to LogMeIn and does some jiggery pokery to get you directly to your machine desktop.

More Information

The project is up on Google Code at http://code.google.com/p/hotwire/ – I normally prefer to use CodePlex, but the Hotwire name was already taken The Google code site contains a downloadable installer, and the source code should anyone be interested.

Screenshots

Technorati Tags: googlecode, Hotwire, logmein, WPF

One of the most bizarre limitation of the WPF RichTextBox is its hit and miss support for subscript and superscript in text. Although you can set the style quite easily using appropriate command, in order for this property to actually alter the appearance of the text the font needs to be OpenType, and come with a Subscript/Superscript variant, which the vast majority of fonts do not. Obviously in a control that’s designed for user input, restricting what fonts can be used in this way is far from ideal.

An Alternative Approach

Having spent some time poking around inside RichTextBox I would strongly recommend that you don’t. Seriously. The code may well make you physically sick. In the past I have tried to use TextRange.ApplyPropertyValue, which takes a normal DependencyProperty, to attach my own property to a piece of text. You’d imagine this would be pretty straightforward, especially as attaching properties to other types is a fairly fundamental part of WPF, but unfortunately there’s a particularly lovely piece of code that checks to see if the DependencyProperty is on a predefined “allowed” list, and thows an exception if it isn’t. While this chunk of code scuppered my ideas in the past, it did provide a useful place to look for an alternative way to create Subscript and Superscript text.

One of the properties that we are “allowed” to apply to text is Inline.BaselineAlignmentProperty which takes its values from the BaselineAlignment enumeration which includes the following values:

• Top
  A baseline that is aligned to the upper edge of the containing box.
• Center
  A baseline that is aligned to the center of the containing box.
• Bottom
  A baseline that is aligned at the lower edge of the containing box.
• Baseline
  A baseline that is aligned at the actual baseline of the containing box.
• TextTop
  A baseline that is aligned at the upper edge of the text baseline.
• TextBottom
  A baseline that is aligned at the lower edge of the text baseline.
• Subscript
  A baseline that is aligned at the subscript position of the containing box.
• Superscript
  A baseline that is aligned at the superscript position of the containing box.

Subscript and Superscript look exactly like what we want, and amazingly, they actually work To demonstrate the technique I’ve created two simple extension methods that toggle either Sub or Superscript on the selected text:

/// <summary>
/// Toggle Superscript for the currently selected text in a RichTextBox. Does not require the font to be OpenType or have a Superscript font style.
///
/// Doesn't attempt to change/restore the size of the font, just moves the baseline.
/// </summary>
/// <param name="richTextBox">RichTextBox with selected text</param>
public static void ToggleSelectionSuperscript(this RichTextBox richTextBox)
{
    var currentAlignment = richTextBox.Selection.GetPropertyValue(Inline.BaselineAlignmentProperty);

    BaselineAlignment newAlignment = ((BaselineAlignment)currentAlignment == BaselineAlignment.Superscript) ? BaselineAlignment.Baseline : BaselineAlignment.Superscript;
    richTextBox.Selection.ApplyPropertyValue(Inline.BaselineAlignmentProperty, newAlignment);
}

The code checks the current value of the BaselineAlignmentProperty and toggles the value as appropriate. I’ve made no attempt to adjust font size, or do anything clever, so it does look a little goofy, but it proves the concept. The demo application also includes the XAML content of the RichTextBox document so you can see exactly what content it’s producing:

And that’s that, hope it helps someone out You can grab the sample demo from the link below:

RichTextBoxSubSuperscript.zip

Technorati Tags: opentype, richtextbox, workaround, WPF

Localisation is something everyone should really care about. Creating your applications, or websites, in a manner that can be easily localised for different languages and cultures is not only “good practice”, but it may also provide additional opportunities.

Luckily the .NET framework, and WPF, has rich support for localisation, with WPF even having “baked in” support for switching flow direction for right to left languages. On top of that Rick Strahl and Michele Leroux Bustamante compiled an excellent guidance document detailing several technique for localising WPF applications. The documentation, along with sample code, can be found in the WPF Localisation Guidance project on CodePlex.

The document discusses several techniques for localising applications using RESX (resource) files, which is my preferred approach; but each of the techniques has its drawbacks:

• Static Binding. Simple and easy, but lacks support for dynamically switching culture.
• Attached Properties. Look powerful, but lacks support for value convertors and it’s a bit inefficient.
• Markup Extension. A new instance of the helper (complete with event wireup for locale switching) is created for every control, which doesn’t sound ideal and may lead to memory leaks.

All of the techniques are perfectly workable solutions, but with Binding and INotifyPropertyChanged WPF already contains a powerful mechanism for mapping and automatically updating UI elements with data; surely there’s some way we can leverage those? My goal was to attempt to find a way to localise an application with the following criteria:

• Use the standard Binding syntax so we can support value convertors.
• No complicated markup extensions.
• Provide a mechanism for code to “register” resources that can be consumed anywhere in the application, even from other PRISM modules.
• Be able to cleanly switch locales, without restarting the application or closing/reopening screens.
• Support the design experience with a minimum of fall back values when in design mode.

The Result – Localisation Using Binding

If you just want to see the code, there’s a basic implementation, and a PRISM demonstration, at the end of the article. Both implementations use the same basic “moving parts”:

LocalisationHelper

In essence this is our ViewModel. There are two key pieces of code here, first being:

public string this[string Key]
{
    get
    {
        if (!validKey(Key))
            throw new ArgumentException(@"Key is not in the valid [ManagerName].[ResourceKey] format");

        if (DesignHelpers.IsInDesignModeStatic)
            throw new Exception("Design mode is not supported");

        return _resourceManager.GetResourceString(GetManagerKey(Key), GetResourceKey(Key));
    }
}

This allows us to bind elements to the LocalisationHelper and provide a “key” which will be used to lookup the correct resource manager and resource string. Our binding uses a little known syntax that looks like this (take note of the initial “.”):

{Binding Path=.[MyResourceManager.MyResourceString]}

To provide design support we throw an exception if we detect design mode (using code from Laurent Bugnion’s MVVM Light Toolkit) so the FallbackValue can be used instead. I’m not too keep on throwing an exception, but I couldn’t see a cleaner way to “fail” the binding.

The other important code hooks an event that fires when the locale changes, and fires a NotifyPropertyChangedEvent with an empty property string. This triggers a refresh for all controls that have bindings to the LocalisationHelper.

ResourceManagerService

The ResourceManagerService provides several functions:

• The ability to register ResourceManagers – these are automatically generated by Visual Studio when you create RESX files and are used to load the locale specific strings.
• Retrieve a resource string from a given ResourceManager.
• Get and set the current locale. A locale consists of an IETF language tag (such as en-GB) and a boolean to indicate whether the locale uses a right to left flow direction.
• A event that is fired when the locale changes. This is hooked by the LocalisationHelper, for firing PropertyChanged events, and also by the main Window which uses the right to left flag to set the flow direction.

Give Me The Code Already!

There are two samples attached. The first is a simple application that uses a static ResourceManagerService that shows the basic implementation. The second is a PRISM based application that uses the container/service locator, EventAggregator, weak references, and several different modules to give a more “advanced” example.

ResourceTest.zip

PRISMResourceTest.zip

Conclusion

I haven’t yet used this solution in anger, but it certainly seems to “tick all the boxes” from my initial requirements. Comments, suggestions, criticisms and flames are welcomed

Technorati Tags: localisation, localization, resourcemanager, resx, WPF

Consider the following simple class for managing storage and retrieval of custom classes in the Windows Clipboard using WPF:

using System;
using System.Windows;

namespace ClipboardTest.Services
{
    public class ClipboardService : IClipboardService
    {
        public bool ContainsData<T>() where T:class
        {
            return Clipboard.ContainsData(typeof(T).ToString());
        }

        public void SetData<T>(T data) where T:class
        {
            Clipboard.SetData(typeof(T).ToString(), data);
        }

        public T GetData<T>() where T : class
        {
            return Clipboard.GetData(typeof(T).ToString()) as T;
        }
    }
}

Simple stuff, but it lets me abstract the clipboard away and remove the usual “magic string” approach for clipboard types.

Now consider the following basic tests:

using ClipboardTest.Services;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace ClipboardTest.Test.Services
{
    public class TestPayload
    {
        public string Data { get; set; }
    }

    [TestClass]
    public class ClipboardServiceTests
    {
        [TestMethod]
        public void SetData_CustomClass_ClipboardContainsInstanceOfClass()
        {
            string data = @"More Cowbell";
            var clipboardService = new ClipboardService();

            clipboardService.SetData<TestPayload>(new TestPayload() { Data = data });

            Assert.IsTrue(clipboardService.ContainsData<TestPayload>());
        }

        [TestMethod]
        public void SetDataGetData_CustomClass_ReturnsEquivilantClass()
        {
            string data = @"More Cowbell";
            var clipboardService = new ClipboardService();

            clipboardService.SetData<TestPayload>(new TestPayload() { Data = data });
            var output = clipboardService.GetData<TestPayload>();

            Assert.IsNotNull(output);
            Assert.AreEqual(data, output.Data);
        }
    }
}

Again, all very simple. The first test checks to make sure that the class gets stored onto the clipboard, and the second checks to see if the class we get back off the clipboard is the same as the one we put in.

The more astute among you have probably spotted the problem in the test code already, but the resultant symptoms are a little confusing.

System.OutOfMemoryException?

When we run the tests the first test runs absolutely fine, but the second test crashes out with a System.OutOfMemoryException. A bit more digging showed that storing and retrieving standard types such as strings, ints etc all worked fine, but my own class was throwing an exception.

Checking good old MSDN threw up the following statement:

An object must be serializable for it to be put on the Clipboard.

Seeing as I had stupidly forgotten to add the SerializableAttribute to the TestPayload class that definitely explained why things weren’t working as I expected; but it didn’t really explain the actual behaviour I was seeing. Another quote from MSDN, but from the WinForms documentation, stated:

If you pass a non-serializable object to a Clipboard method, the method will fail without throwing an exception.

So from that I would expect SetData to silently fail, and for nothing to be on the clipboard. However the first test above clearly shows that the clipboard at least thinks that something of our specified type has been added to the clipboard – it just throws an exception when we try and retrieve it again. Marking the payload class as serializable did fix the issue, but the behaviour I was seeing certainly didn’t make that obvious!

Just out of interest I tested the same code using the WinForms Clipboard class, which looks to all intents and purposes exactly the same as the WPF one, and that did fail silently and returned null from GetData.

Conclusion

So, after all that rambling, the conclusion is that if you are working with the Clipboard in WPF and you are getting System.OutOfMemoryExceptions that don’t seem to make any sense, then you’ve probably forgotten to add the SerializableAttribute to whatever class you placed on the Clipboard.

Technorati Tags: clipboard, OutOfMemoryException, System.OutOfMemoryException, WPF

Yesterday I was working on a small prototype, which I will be blogging about shortly, and ran across the common problem of my bindings not updating. A very common problem, and one that’s usually a very simple fix once you’ve tracked it down.

Yes, I’m an Idiot!

Normally my ViewModels inherit from my ViewModelBase base class, which provides a RaisePropertyChanged method and, when in debug mode, uses reflection to check if the property name is valid. Now I’d recently refactored the code so this particular ViewModel wasn’t using the base class, so my first instinct was that I’d simply mistyped the property name magic string in the event – but that was all fine.

I threw in a few breakpoints and I could see my ViewModel was changing, I could see the OnPropertyChanged method being hit, but there didn’t seem to be any listeners and as a result my UI was just ignoring the changes.

After a few minutes of head scratching I noticed that although my class was firing the PropertyChanged event correctly, I hadn’t added INotifyPropertyChanged to my class declaration when I removed the base class! So although I was firing an event that looked like INotifyPropertyChanged.PropertyChanged, I was actually just firing my own event with the same name

Conclusion

So there you have it, I’m an idiot The moral of the story is, when your bindings aren’t working check the obvious:

1. The property name is correct. A base class that checks this in debug mode can be useful, or failing that, watch the Output window.
2. Check you are actually implementing INotifyPropertyChanged and not just firing events that happen to have the same name

Technorati Tags: binding, inotifypropertychanged, Silverlight, WPF