WPF: Debugging your UI in Expression Blend

.NET, Blend, Technical stuff, Work, WPF
See comments


Here’s a cool trick, which I thought of after reading this comment and this post.
The good thing to remember is that Expression Blend is a (maybe the first) Microsoft application entirely written in WPF. I always thought it was pretty cool. Well, even cooler than I thought: When load a project in Blend, the code you wrote is actually executed!Of course there are some caveats (see below), but what it allows is to place a breakpoint in your code (for example in a User Control’s constructor), and to attach the Visual Studio 2005 debugger to blend.exe. Then, when you open the window containing the user control (again, see the “caveats” below), the user control’s constructor gets executed, and you can then debug.


So why is this useful? In my case, I was puzzled, because when I was opening my user control in Blend, some UI elements wouldn’t appear. These UI elements’ look&feel is defined by ControlTemplates located in the resources. Depending on a parameter (integer), a converter will pick the correct template from the resources. The syntax for the binding is something like that:
    Template="{Binding ElementName=WindowRoot,
      Converter={StaticResource IDToTemplateConverter}}" />

Binding with a converter

However, nothing appeared in Blend. Many explanations were possible: Either the converter was not found, or there was an error in the Convert method, or the Template was not found and null was returned.
By placing a breakpoint in the Convert method, and by attaching the debugger on Blend, I was able to find out that it was indeed the Template that was not found (and again, see “caveats” below). To solve the issue, I copied the templates in the user control’s resources temporarily, and then everything worked as expected.


Not everything is perfect in Blend, though. IdentityMan Nathan Dunlap helped me to find a workaround for the first issue. The other issues are annoying, but aren’t really blocking.
  • Issue#1: Expression Blend has a lot of problems finding resources which are not local to the control currently edited. If the resources are located in an external assembly, and linked using a ResourceDictionary’ Source property, then Blend is unable to display the resources correctly. You can still edit them in the resource dictionary directly, but they won’t show in the user control.
    The workaround is to copy the resources locally, to work on them, and then copy them back to the external resource dictionary. While this is annoying, it’s not that bad, and Blend supports drag&drop between resource dictionaries.
ResourceDictionary linked from another assembly:
    Source="/MyOtherAssembly;component/MyResources.xaml" />
  • Issue #2 (benign): If you modify the code behind, the changes don’t show automatically in Blend. You must recompile the assembly, then you must close the window in the Design view, and then reopen it. Only then will the modified code be run, and the changes will appear.
  • Issue #3: When you open a Window (or a user control), it’s constructor is not executed. That’s annoying, because if you place code to initialize the UI elements in the constructor, this code is not run, and nothing appears in Blend’s design view. If you open a Window containing a User Control, the User Control’s constructor is run, but not the Window’s constructor. If you open a User Control containing children User Controls, each child’s constructor is run, but not the parent’s.
To demonstrate issue #3, let’s create a Window (W1) containing one User Control (UC1). This User Control itself contains another User Control (UC2). W1, UC1 and UC2 each contain one Label. The content of the Label is set to “Not initialized”. However, in W1, UC1 and UC2’s constructor, the label’s content is set to “It worked”.
When you open the different objects in Blend’s design view, here is what you get:
Opening UC2:

Opening UC2

Opening UC1:

Opening UC1

Opening W1:

Opening W1

These issues are not critical, and workarounds exists. It would be nice, however, if they were solved in Blend’s future release. The designer’s (and the integrator’s) work would be facilitated!
Previous entry | Next blog entry

Comments for WPF: Debugging your UI in Expression Blend