Designer Code
Its time to step away from web services, log aggregation and AWS for a little while.
Its time to do some UI work! Not HTML though unfortunately, Windows desktop software.
The flagship application that my team maintains is an old (15+ years) VB6 application. It brings in a LOT of money, but to be honest, its not the best maintained piece of software I’ve ever seen. Its not the worst either, which is kind of sad. Like most things it falls somewhere in the middle. More on the side of bad than good though, for sure.
In an attempt to keep the application somewhat current, it has a .NET component to it. I’m still not entirely sure how it works, but the VB6 code uses COM to call into some .NET functionality, primarily through a message bus (and some strongly typed JSON messages). Its pretty clever actually, even if it does lead to some really strange threading issues from time to time.
Over the years, good sized chunks of new functionality have been developed in .NET, with the UI in Windows Forms.
Windows Forms is a perfectly fine UI framework, and don’t let anyone tell you different. Sure it has its flaws and trouble spots, but on the whole, it works mostly as you would expect it to, and it gets the job done. The downside is that most Windows Forms UI’s look the same, and you often end up with business logic being tightly coupled to the UI. When your choice is Windows Forms or VB6 though, well, its not really a choice.
For our most recent project, we wanted to try something new. Well, new for the software component anyway, certainly not new to me, some of the other members of the team, or reality in general.
WPF.
Present that Framework
I’m not going to go into too much detail about WPF, but its the replacement for Windows Forms. It focuses on separating the actual presentation of the UI from the logic that drives it, and is extremely extensible. Its definitely not perfect, and the first couple of versions of it were a bit rough (Avalon!), but its in a good spot now.
Personally, I particularly like how it makes using the MVVM (Model-View-ViewModel) pattern easy, with its support for bindings and commands (among other things). MVVM is a good pattern to strive for when it comes to developing applications with complicated UI’s, because you can test your logic independent of the presentation. You do still need to test it all together obviously, because bindings are code, and you will make mistakes.
I was extremely surprised when we tried to incorporate a WPF form into the VB6 application via the .NET channels it already had available.
Mostly because it worked.
It worked without some insane workaround or other crazy thing. It just worked.
Even showing a dialog worked, which surprised me, because I remember having a huge amount of trouble with that when I was writing a mixed Windows Form/WPF application.
I quickly put together a fairly primitive framework to support MVVM (no need to invest into one of the big frameworks just yet, we’re only just starting out) and we built the new form up to support the feature we needed to expose.
That was a particularly long introduction, but what I wanted to talk about in this post was using design time variables in WPF to make the designer actually useful.
Intelligent Design
The WPF designer is…okay.
Actually, its pretty good, if a little bit flakey from time to time.
The problem I’ve encountered every time I’ve used MVVM with WPF is that a lot of the behaviour of my UI component is dependent on its current data context. Sure, it has default behaviour when its not bound to anything, but if you have error overlays, or a message channel used to communicate to the user, or expandable bits within an Items Control whose items have their own data templates, it can be difficult to visualise how everything looks just from the XAML.
It takes time to compile and run the application as well (to see it running in reality), even if you have a test harness that opens the component you are working on directly.
Tight feedback loops are easily one of the most important parts of developing software quickly, and the designer is definitely the quickest feedback loop for WPF by far.
Luckily, there are a number of properties that you can set on your UI component which will only apply at design time, and the most useful one is the design time DataContext.
This property, when applied, will set the DataContext of your component when it is displayed in the designer, and assuming you can write appropriate classes to interface with it, gives you a lot of power when it comes to viewing your component in its various states.
Contextual Data
I tend towards a common pattern when I create view models for the designer. I will create an interface for the view model (based on INotifyPropertyChanged), a default implementation (the real view model) and a view model creator or factory, specifically for the purposes of the designer. They tend to look like this (I’ve included the view model interface for completeness):
namespace Solavirum.Unspecified.ViewModel
{
public interface IFooViewModel : INotifyPropertyChanged
{
string Message { get; }
}
}
namespace Solavirum.Unspecified.View.Designer
{
public class FooViewModelCreator
{
private static readonly _Instance = new FooViewModelCreator();
public static IFooViewModel ViewModel
{
get
{
return _Instance.Create();
}
}
public IFooViewModel Create()
{
return new DummyFooViewModel
{
Message = "This is a message to show in the designer."
};
}
private class DummyFooViewModel : BaseViewModel, IFooViewModel
{
public string Message { get; set; }
}
}
}
As you can see, it makes use of a private static instance of the creator, but it doesn’t have to (It’s just for caching purposes, so it doesn’t have to be recreated all the time, its probably not necessary). It exposes a readonly view model property which just executes the Create function, and can be bound to in XAML like so:
<UserControl
x:Class="Solavirum.Unspecified.View.FooView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:Designer="clr-namespace:Solavirum.Unspecified.View.Designer"
mc:Ignorable="d"
d:DataContext="{x:Static Designer:FooViewModelCreator.ViewModel}">
<Grid>
<TextBlock Text="{Binding Message}" />
</Grid>
</UserControl>With this hook into the designer, you can do all sorts of crazy things. Take this creator for example:
namespace Solavirum.Unspecified.View.Designer
{
public class FooViewModelCreator
{
private static readonly FooViewModelCreator _Instance = new FooViewModelCreator();
public static IFooViewModel ViewModel
{
get { return _Instance.Create(); }
}
public IFooViewModel Create()
{
var foreground = TaskScheduler.Current;
var messages = new List<string>()
{
"This is the first message. Its short.",
"This is the second message. Its quite a bit longer than the first message, and is useful for determining whether or not wrapping is working correctly."
};
var vm = new DummyFooViewModel();
var messageIndex = 0;
Task.Factory.StartNew
(
() =>
{
while (true)
{
Thread.Sleep(TimeSpan.FromSeconds(5));
var newMessage = messages[messageIndex];
messageIndex = (messageIndex + 1)%messages.Count;
Task.Factory.StartNew
(
() => vm.Message = newMessage,
CancellationToken.None,
TaskCreationOptions.None,
foreground
);
}
},
CancellationToken.None,
TaskCreationOptions.LongRunning,
TaskScheduler.Default
);
return vm;
}
private class DummyFooViewModel : IFooViewModel
{
private string _Message;
public string Message
{
get { return _Message; }
set
{
_Message = value;
RaisePropertyChanged("Message");
}
}
public event PropertyChangedEventHandler PropertyChanged;
private void RaisePropertyChanged(string propertyName)
{
var handlers = PropertyChanged;
if (handlers != null)
{
handlers(this, new PropertyChangedEventArgs(propertyName));
}
}
}
}
}It uses a long running task to change the state of the view model over time, so you can see it in its various states in the designer. This is handy if your view model exposes an error property (i.e. if it does a refresh of some sort, and you want to notify the user in an unobtrusive way when something bad happens) or if you just want to see what it looks like with varying amounts of text or something similar. Notice that it has to marshal the change onto the foreground thread (which in the designer is the UI thread), or the property changed event won’t be picked up by the binding engine.
Once you’ve setup the creator and bound it appropriately, you can do almost all of your UI work in the designer, which saves a hell of a lot of time. Of course you can’t verify button actions, tooltips or anything else that requires interaction (at least to my knowledge), but its still a hell of a lot better than starting the application every time you want to see if your screen looks okay.
Getting Inside
Now, because you are running code, and you wrote that code, it will have bugs. There’s no shame in that, all code has bugs.
Its hard to justify writing tests for designer specific support code (even though I have done it), because they don’t necessarily add a lot of value, and they definitely increase the time required to make a change.
Instead I mostly just focus on debugging when the designer view models aren’t working the way that I think they should.
In order to debug, you will need to open a second instance of Visual Studio, with the same project, and attach it to the XAML designer process (XDesProc). Now, since you have two instances of Visual Studio, you might also have two instances of the XAML designer process, but its not hard to figure out the right one (trial and error!). Once you’ve attached the process you can put breakpoints in your designer specific code and figure out where its going wrong.
I’ll mention it again below, but the app domain for the designer is a little bit weird, so sometimes it might not work at all (no symbols, breakpoints not being hit, etc). Honestly, I’m not entirely sure why, but a restart of both instances of Visual Studio, combined with a fresh re-compilation usually fixes that.
Gotchas
There are a few gotchas with the whole designer thing I’ve outlined above that are worth mentioning.
The first is that If you do not version your DLL appropriately (within Visual Studio, not just within your build server), you will run into issues where old versions of your view model are being bound into the designer. This is especially annoying when you have bugs, as it will quite happily continue to use the old, broken version. I think the designer only reloads your libraries when it detects a version change, but I can’t back that up with proof.
The solution is to make sure that your version changes every time when you compile, which honestly, you should be doing anyway. I’ve had success with just using the reliable 0.0.* version attribute in the assembly when the project is compiled as debug (so using an #IF DEBUG). You just have to make sure that whatever approach you use for versioning in your build server doesn’t clash with that.
The second gotcha is that the app domain for the designer is a bit…weird. For example, Ninject won’t automatically load its extension modules in the designer, you have to load them manually. For Ninject specifically, this is a fairly straightforward process (just create a DesignerKernel), but there are other issues as well.
Sometimes the designer just won’t run the code you want it to. Typically this happens after you’ve been working on it for a while, constantly making new builds of the view model creator. The only solution I’ve found to this is just to restart Visual Studio. I’m using Visual Studio 2013 Update 5, so it might be fixed/better in 2015, but I don’t know. Its not a deal breaker anyway, basically just be on the lookout for failures that look like they are definitely not the fault of your code, and restart Visual Studio before you start pulling your hair out.
Conclusion
I highly recommend going to the extra effort of creating view models that can be bound in your component at design time. Its a great help when you’re building the component, but it also helps you to validate (manually) whether or not your component acts as you would expect it to when the view model is in various states.
It can be a little bit difficult to maintain if your code is changing rapidly (breaking view models apart can have knock-on effects on the creator for example, increasing the amount of work required in order to accomplish a change), but the increase in development speed for UI components (which are notoriously fiddly anyway) is well worth it.
Its also really nice to see realistic looking data in your designer. It makes the component feel more substantial, like it actually might accomplish something, instead of being an empty shell that only fills out when you run the full application.