Category Archives: C#

Embedding code in your XAML

First off a disclaimer. Just because you can do this doesn’t mean you should :)

<x:Code>
   <![CDATA[
   private void OKButton_Click(object sender, RoutedEventArgs e)
   {
      MessageBox.Show("OK Clicked");
   }
   ]]>            
</x:Code>

<Button Content="OK" Width="80" Margin="3" Click="OKButton_Click" />

There’s not a lot to say about this one except that it’s possible to embed code in XAML. Obviously it’s easier to code it, generally speaking, in the code behind and better still in the view model. But the option is there :)

Investigating Ninject

Whilst I’ve used IoC frameworks such as Unity, MEF, Spring.net etc. in the past, I’ve not gotten around to playing with Ninject. So time to have a play.

First off I created a simple interface, IService and corresponding implementing LocalService

public interface IService
{
   void Run();
}

public class LocalService : IService
{
   public void Run()
   {
      Console.WriteLine("Local Service");
   }
}

Now I created a simple client object

public interface IClient
{
   IService Service { get; }

   void Run();
}

public class Client : IClient
{
   public Client(IService service)
   {
      Service = service;
   }

   public IService Service { get; private set; }

   public void Run()
   {
      Service.Run();
   }
}

So as you can see the idea is simple. A client requires an IService passed by the IoC into the constructor. At some point we’ll call the client’s Run method and expect a LocalService to run. Obviously error handling etc. omitted for brevity.

Now let’s create the configuration/bindings to allow Ninject to inject the required service into the client.

var kernel = new StandardKernel();

kernel.Bind<IService>().To<LocalService>();
kernel.Bind<IClient>().To<Client>();

var client = kernel.Get<IClient>();
client.Run();

What about if we have multiple IService implementations, see the changes below which include the client accepting an array of IService and the kernel code includes an additional binding.

public class RemoteService : IService
{
   public void Run()
   {
     Console.WriteLine("RemoteService");
   }
}

public interface IClient
{
   IService[] Service { get; }

   void Run();
}

public class Client : IClient
{
   public Client(IService[] service)
   {
      Service = service;
   }

   public IService[] Service { get; private set; }

   public void Run()
   {
      foreach(IService service in Service)
         service.Run();
   }
}

var kernel = new StandardKernel();

kernel.Bind<IService>().To<LocalService>();
kernel.Bind<IService>().To<RemoteService>();
kernel.Bind<IClient>().To<Client>();

var client = kernel.Get<IClient>();
client.Run();

So using Ninject to inject into a constructor is simple. Now let’s make a change to the client constructor by removing the parameter and instead use property injection.

public class Client : IClient
{
   [Inject]
   public IService[] Service { get; set; }

  // the Run method remains unchanged as does the binding code
}

Investigating Memory – Strings

A while back I had to investigate why our application seemed to be using a large amount of memory in certain usage patterns. What we would find is that several calls to a web service would cause an OutOfMemoryException on the client.

Note: The underlying problem was the good old, “references not being released” to an object and thus garbage collection not taking place. But more interesting at the time was the information I found from the steps below.

To investigate the memory usage I loaded up WinDbg and attached (F6) to the instance of the application I wanted to investigate. Then carried out the following steps.

  • I typed .load sosex into the WinDbg command line (see http://stevestechspot.com)
  • I typed !dumpheap -stat into the WinDbg command line to view the memory

At the end of the heap dump I noticed the type consuming the largest amount of memory (by quite a long way) was the humble System.String. This tweaked my interest and so I dug deeper using WinDbg.

  • I typed !dumpheap -strings into WinDbg

This took a while to complete (due to the size of the application) but I noticed that when the dump was completed there were a large number of strings which seemed to have a very large number of instances duplicates stored in memory. Amounting to a hefty amount of the memory being used for the same string stored thousands of times.

Note: The problem with !dumpheap -strings is that it does not output the object reference because it’s outputting a summary of each string’s usage, but from this we can see the strings that take the most memory and/or most instances of and the use the sosex command !strings to inspect each instance in more detail. Type !help !strings to view help for the command. One useful option is !strings /m:

What was happening was that large amounts of data were being retrieved from our web services and in that data was a massive number of duplicate strings. Unfortunately I could do nothing with the web service itself, but I could attempt to address the strings in the client application.

As you may know there’s a static method on the String class called Intern. In essence this acts as an application wide string cache (or more precisely an AppDomain cache), calling it like this

o.Name = String.Intern(o.Name);

Will in essence replace the o.Name string which a reference to the one stored in the application cache, thus the previous o.Name string can be garbaged collected as it’s no longer referenced.

This reduced the amount of duplicates and memory immediately, however there’s an obvious problem with the String.Intern and that is it’s an AppDomain cache. This means that as we read strings from our webservices these add to the cache and never get garbage collected, slowly added more and more unique strings to the cache. This is fine for const strings which are automatically interen’d but not so good for an application mean’t to run pretty much 24/7.

I initially looked to implement my own Dictionary based cache but almost everything has been done by somebody else on the web, so after a short search I came across the StringReference class which did exactly what I wanted. It allows us to use the good bits from Intern but with the ability to clean up unused strings over time.

A simple WPF TriggerAction to turn events into commands

This is nothing new. I know of several MVVM frameworks that do this, but this was my take on a solution for the following:

So you have events on a UIElement, for example a Button has MouseEnter and MouseLeave (amongst others). By default the events require an event handler which would might be placed in the “code behind” in the view itself. But this is no use if, for example a MouseEnter should update some data from the view model unless you want to do more coding in the view to access the view model and makes calls directly on it, which is a somewhat against the spirit of MVVM. So what would be cool is if the MouseEnter could instead be bound to a view model command instead.

Being that part of the mechanism already exists in EventTriggers then we just need to supply a trigger action to bind to the view model.

For example the XAML might look like:

<Button Content="Cancel" Width="80" Margin="3" >
   <i:Interaction.Triggers>
      <i:EventTrigger EventName="MouseEnter">
         <controls:CommandAction Command="{Binding ClearSearch}" />
      </i:EventTrigger>
   </i:Interaction.Triggers>
</Button>

The code for the TriggerAction is simple

public class CommandAction : TriggerAction<DependencyObject>
{
   public static readonly DependencyProperty CommandProperty =
	DependencyProperty.Register("Command", typeof(ICommand), typeof(CommandAction),
	new PropertyMetadata(null, OnCommandChanged));

   public static readonly DependencyProperty CommandParameterProperty =
	DependencyProperty.Register("CommandParameter", typeof(object), typeof(CommandAction),
	new PropertyMetadata(null, OnCommandParameterChanged));

   private IDisposable canExecuteChanged;

   public ICommand Command
   {
      get { return (ICommand)GetValue(CommandProperty); }
      set { SetValue(CommandProperty, value); }
   }

   public object CommandParameter
   {
      get { return GetValue(CommandParameterProperty); }
      set { SetValue(CommandParameterProperty, value); }
   }

   private static void OnCommandChanged(DependencyObject sender, 
                   DependencyPropertyChangedEventArgs e)
   {
      CommandAction ev = sender as CommandAction;
      if(ev != null)
      {
         if (ev.canExecuteChanged != null)
	 {
	    ev.canExecuteChanged.Dispose();
	 }

	 ICommand command = e.NewValue as ICommand;
	 if (command != null)
	 {
	    ev.canExecuteChanged = Observable.FromEventPattern(
			x => command.CanExecuteChanged += x,
			x => command.CanExecuteChanged -= x).Subscribe
			(_ => ev.SynchronizeElementState());
	 }
      }
   }

   private static void OnCommandParameterChanged(DependencyObject sender,
            DependencyPropertyChangedEventArgs e)
   {
      CommandAction ev = sender as CommandAction;
      if (ev != null)
      {
         ev.SynchronizeElementState();
      }
   }

   private void SynchronizeElementState()
   {
      ICommand command = Command;
      if (command != null)
      {
         FrameworkElement associatedObject = AssociatedObject as FrameworkElement;
	 if (associatedObject != null)
	 {
	    associatedObject.IsEnabled = command.CanExecute(CommandParameter);
	 }
      }	
   }

   protected override void Invoke(object parameter)
   {
      ICommand command = Command;
      if(command != null)
      {
         command.Execute(CommandParameter);
      }
   }
}

We derive our class from TriggerAction and declare any dependency properties etc. we want on it. So if you ignore all the setting up of Command & CommandParameter code, this really boils down to the override of the Invoke method. This is what’s called when the trigger condition is met.

Blend Behaviors in WPF

A quick post about blend behaviors in WPF. A behavior (from the System.Windows.Interactive assembly) allows us to add functionality to elements within the UI tree. An example might better serve to describe what one is and how to write one.

Let’s make things simple and say we have a UI element which we want to fade into the background when not focus. So we can create a class derived from Behavior<>. Looking at the properties on a UIElement this will suffice for our needs so we’ll derive our FadeOnLostFocusBehavior (bit of a mouthful) from Behavior.

If we jump straight to the code we get something like

public class FadeOnLoseFocusBehavior : Behavior<UIElement>
{
   private const float FADED = 0.2f;

   protected override void OnAttached()
   {
      AssociatedObject.LostFocus += AssociatedObject_LostFocus;
      AssociatedObject.GotFocus += AssociatedObject_GotFocus;

      // this just ensures a default state of faded for the control
      AssociatedObject.Opacity = FADED;

      base.OnAttached();
   }

   protected override void OnDetaching()
   {
      AssociatedObject.LostFocus -= AssociatedObject_LostFocus;
      AssociatedObject.GotFocus -= AssociatedObject_GotFocus;

      base.OnDetaching();
   }

   private void AssociatedObject_LostFocus(object sender, RoutedEventArgs e)
   {
      AssociatedObject.Opacity = FADED;
   }	

   private void AssociatedObject_GotFocus(object sender, RoutedEventArgs e)
   {
      AssociatedObject.Opacity = 1;
   }
}

The above is very simple. When we attach the behavior to the UIElement we connect to the required events on the AssociatedObject. When we detach from the UIElement we detach from the events on the AssociatedObject. The rest is self-explanatory.

The XAML for this example would look like

<Button Content="Cancel" Width="80" Margin="3" >
   <i:Interaction.Behaviors>
      <controls:FadeOnLoseFocusBehavior />
   </i:Interaction.Behaviors>
</Button>

_ in C#

This is a quirky post. Something I’ve been using for a while is the _ in situations where I’ve an anonymous delegate with one argument where I don’t care about the argument, for example

ThreadPool.QueueUserWorkItem(_ => DoSomething());

But never thought of using it as a class name or variable name (not sure why I hadn’t thought of it apart from it seeming like a mad thing to do :)), for example

class _
{
   // members
}

public void Main()
{
   _ _ = new _();
}

Note: I’m not saying this is a good thing to use, just that it’s possible

32-bit/64-bit incompatibility fun

So, I’m working on a C#/.NET application which currently uses a 32-bit version of TIBCO RV. The company I’m working for is (slowly) moving from Windows XP over to Windows 7 (and the brave new world of 64-bit computing). However they’re obviously wanting to test their suite of in-house application and ensure they’re all run correctly on the 64-bit machines.

I’ve been tasked with ensuring our application works. Ofcourse immediately we hit a problem which was the use of the 32-bit TIBCO RV. The application, by default, was built with the “Any CPU” configuration. The way the JIT works is that it will JIT compile “Any CPU” code to the architecture of the CPU, so on a 32-bit OS it’s 32-bit and on a 64-bit OS it’s run as a 64-bit application – which is how it obviously should be.

But with the inclusion of the 32-bit DLL and the JIT switching the application to 64-bit obviously caused a bit of a problem and we were seeing the “System.BadImageFormatException” exception when the application attempted to load the 32-bit DLL. Ofcourse this is to be expected as you can’t mix 64-bit and 32-bit in the same application.

Apart from the obvious solution of getting a 64-bit version of TIBCO RV installed (which is ultimately where we’d hope to end up). How do we solve this problem now?

So the key to solving this is the “Any CPU” configuration. If we create an x86 configuration we can force the JIT to build for a 32-bit architecture and x64 will force the code to 64-bit.

Now here I made a subtle mistake which I’m going to share with you. I created a new configuration whereby all projects were switched to “x86” I compiled the application without a hitch and deployed it, only to find it still failing. Part of the problem was I didn’t have a 64-bit machine to run on, so this was a rather slow process of building, deploying and testing :)

To cut a long story short (too late I know). I eventually got some time on a 64-bit machine. I rebuilt the client on this machine in “x86” mode and strangely (unlike building it on the 32-bit machine) I got loads of errors. Seemingly incompatible assemblies all pointing to a bunch of third party UI assemblies (which I assume are built as Any CPU) – now I’ve not confirmed this yet but I wondered at this point whether the problem is to do with some of my assemblies configured as x86 and others as Any CPU. That’s something I need to look into.

Anyway further investigation brought to my attention the following application

corflags /32bit+

I used this on the EXE only and ran the application an it worked perfectly.

Switching back to Visual Studio I changed only the EXE’s project to build x86 code. I recompiled the solution and had no incompatibilities during the build. Then I ran the application and all worked perfectly.

So it appears just setting the entry point (in this case the EXE) to x86 solved the problem, seemingly forcing the application into 32-bit mode.

Debugger Attributes

DebuggerDisplayAttribute

One attribute that I find very useful, but for some reason I always forget what it’s called, is the DebuggerDisplayAttribute. This allows us to display a field or combination of fields within the debugger window, for example when we move the mouse over a variable whilst stepping through code. Instead of just seeing the type name we can display something possibly more meaningful.

[DebuggerDisplay("Name: {FullName}, Role: {OrganisationRole}")]
public class User
{
   // ...
   public string FullName { get; set; }
   public string OrganisationRole { get; set; }
}

The above will now display something like

Name: John Smith, Role: Team Lead

in the debugger.

DebuggerStepThroughAttribute

Even with my poor memory, this is one I remember well as I use it quite a lot.

When in debug mode stepping through code often we end up stepping into properties or other code which maybe makes no sense to step through. Either the code is simple, like a getter simply returning a value or make it’s boiler plate code for calling a webservice.

Using the DebuggerStepThroughAttribute (as below) we can tell the debugger to basically step-over the code contained within the property or method.

public string this[string key]
{
   [DebuggerStepThrough]
   get { return parameters[key]; }
}

CallerMemberNameAttribute

Once very cool feature of .NET 4.5 which passed me by until now is the CallerMemberNameAttribute. Whilst using Reactive UI on a project I accidentally started using an overload of RaiseAndSetIfChanged without the first param being of the form x=> x.PropertyName. Yet the application compiled and seemed to work fine.When I realised my mistake I took a look at the source for ReactiveUI and noticed the use of the [CallerMemberName] attribute on the last argument of the method.

Have a read of the CallerMemberNameAttribute documentation for further info. But basically you can have a string as an optional param with the CallerMemberNameAttribute declaration preceding it and the called method can now find the name of the method that called it. Plus other attributes in CallerFilePathAttribute and CallerLineNumberAttribute which the called method can even get the file path of he source and line number of the where the method was called from. See Caller Information for more.

This is very useful (as shown by it’s use in ReactiveUI) as instead of passing a string from a property for an OnPropertyChanged event with the possibility of typos etc. we can instead let the compiler services handle this using the CallerMemberNameAttribute

public string MyProperty
{
   get { return myProperty; }
   set
   {
      if(myPropery != value)
      {
         myProperty = value;
         //OnPropertyChanged("MyProperty"); -- Replaced
         OnPropertyChanged();
      }
   }
}

private void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
   // raise a property changed even or whatever with the propertyName string
}

WPF Composite Control

Over the years I’ve implemented this code in Delphi, C++ and C# with WinForms. I finally had reason to implement it again, but now in WPF. There were a few interesting issues to solve, so I’ve listed them below.

1. I wanted a simple EllipseTextBox control. A textbox with associated “…” button. The XAML for this is simple enough (I’ve excluded all the UserControl namespaces etc.).

<Grid>
   <Grid.ColumnDefinitions>
      <ColumnDefinition Width="*" />
      <ColumnDefinition Width="Auto" />
   </Grid.ColumnDefinitions>
   <TextBox Grid.Column="0" />
   <Button Grid.Column="1" Content="..." />
</Grid>

Whilst this produces a Button next to a TextBox I obviously needed to add code behind to allow me to bind to the Button Command and TextBox Text properties.

2. So in the code behind I needed to write a few lines of code, but as the TextBox already has a Text property and the Button a Command property, I wanted to set up the relevant DependencyProperty to pass the Text and Command through to the TextBox and Button. To do this I added the following.

public partial class EllipseTextBox : UserControl
{
	public static readonly DependencyProperty TextProperty = TextBox.TextProperty.AddOwner(typeof (EllipseTextBox));
	public static readonly DependencyProperty CommandProperty = ButtonBase.CommandProperty.AddOwner(typeof (EllipseTextBox));

	public EllipseTextBox()
	{
		InitializeComponent();
	}

	public string Text
	{
		get { return (string)GetValue(TextProperty); }
		set { SetValue(TextProperty, value); }
	}

	public ICommand Command
	{
		get { return (ICommand)GetValue(CommandProperty); }
		set { SetValue(CommandProperty, value); }
	}
}

Great so now we can have a TextBox and Button displayed along with the code to pass the Command and Text properties through to the Button and TextBox, but this is of little use of the Command is not hooked up directly to the Button in the UserControl and likewise the Text property on the TextBox. So next step is to wire the XAML to the code behind.

3. Thankfully this isn’t difficult (although it’s rather verbose). So if we update the original XAML replacing the TextBox and Button code with the following

<TextBox Grid.Column="0" Text="{Binding Text, RelativeSource={RelativeSource FindAncestor, AncestorType=ControlLibrary:EllipseTextBox, AncestorLevel=1}}" />
<Button Grid.Column="1" Content="..." Width="{Binding ActualHeight, RelativeSource={RelativeSource Self}}" Command="{Binding Command, RelativeSource={RelativeSource FindAncestor, AncestorType=ControlLibrary:EllipseTextBox, AncestorLevel=1}}"/>

Note: Another nice little trick while implementing this was that I wanted the Button to be square – so I’ve got the Button Width binding to the ActualHeight of the Button. Well I thought it was nice :)