You may get an error of the form Cannot add content of type 'System.Windows.Style' to an object of type 'System.Windows.ResourceDictionary' when working with WPF and your first reaction would be "What?! Why not!?". Well, the issue is very simple, only it stems from another source entirely: you've just tried to add a Style with the same key as another previously entered style.

I believe this is something that any decent WPF programmer will laugh about, but there it is: I had this control derived from ContentControl and, of course, somewhere in the template I had a ContentPresenter. It all worked very well until I added a resizable option. I had two of these controls on the page, the first would contain a Grid, the other an ItemsControl. When I resized vertically the control, the ItemsControl would remain unchanged whether I made the height bigger or smaller. The Grid, though, would remain the same if enlarging the container and then squash when the size of the container got smaller than its auto size.

I have to say that I think my solution is really silly, but since it works: I've put a ScrollViewer control around the ContentPresenter in the my control template and then set its VerticalScrollBarVisibility to Hidden. This more or less is the same thing as setting overflow:hidden on the web.

As you have probably noticed, a lot of my recent posts have been about WPF. Having to do a demo in this new (for me) technology I had a lot of thing to learn and a lot of brick walls to hit. It was exciting, but also difficult, with new concepts that felt awkward, mind twisting. I even burst one day shouting "I hate WPF".

However, I am now working, temporarily, with ASP.Net (no Silverlight) again. And guess what? At every step where I need to design something, I think in the WPF way and find the web way lacking. Riddle me this, riddle me that. :)

Of course, some might say that this is another proof of my whiny personality. I hate when people say that about me!

I was trying to build a control that has a border around it only in design mode. You do have the static class DesignerProperties and its method GetIsInDesignMode(DependencyObject element) to detect that in code, and you do have a property DesignMode on Components, but one that is not a Dependency property. How can you detect DesignMode in XAML?

Well, looking at the source for DesignerProperties I noticed that it does two things:
  1. Register an attached property called IsInDesignMode to itself
  2. Get/Set that dependency property in the GetIsInDesignMode/SetIsInDesignMode methods

More on how to create attached properties here: How to Create an Attached Property and here: Showing Attached Properties in the Cider/Visual Studio WPF Designer.

So, all I had to do is use a trigger on the IsInDesignMode attached property. For that, these steps must be followed:
  • Add the ComponentModel namespace to your XAML: xmlns:ComponentModel="clr-namespace:System.ComponentModel;assembly=PresentationFramework"
  • Use ComponentModel:DesignerProperties.IsInDesignMode in your Triggers as the Property
  • Use (ComponentModel:DesignerProperties.IsInDesignMode) in your DataTriggers as the Path of Bindings

Please take notice of the brackets around the property when used in Binding Path mode. It is the only way to use attached properties there. It also gives you more advanced intellisense and warnings and a faster type resolution at runtime.

Another thing to take into consideration is that (at least in Silverlight) this mechanism is buggy, at least that's what I found in this blog post.

I don't want to write a long blog entry, just to attract attention to this blog entry from Josh on WPF which is very concise, to the point and also directing to more complex articles that add more detail.

Even so, I want to cite a part which I think is essential to understanding the concept of Dependency Properties: Remember, a DP never really “has” a value…its value depends on various external factors. That’s why they are called dependency properties.

The problem is moot. The StackPanel doesn't work like that. You need to use a DockPanel to make inner children of the Panel stretch vertically and make the Panel fill all available space. The elements inside should have DockPanel.Dock="Top" to fill only the space they require , then no Dock for the element(s) you want to stretch, then DockPanel.Dock="Bottom" for the rest of the elements. That's how you get that "Outlook feel", too.

I was trying to use the Infragistics WPF controls and got stuck in the XamComboEditor. I was setting its ItemsSource to a list of ComboBoxDataItem objects and I wanted to have none of them selected by default. I had tried SelectedIndex -1, SelectedItem {x:Null}, Value {x:Null} to no avail. By some ridiculous functionality, the XamComboEditor would select some item in the middle of the list.

Then, in a flash of luck, I got it right. Value="". That was it! Even if IsEditable was false and the documentation mentioned Value could not be changed if IsEditable is false. Of course, they probably meant the user cannot change the Value not me, the developer, but still. Also, setting the Value to null did not work. Once in a lifetime I am not lazy and use {x:Null} instead of a simple empty string and it backfires. Sheesh!

In order to customize controls the way you want, you can either use a DataTemplate, different specific ControlTemplate properties, use the properties that the controls publish, but in the end, to get it right, you must actually change the ControlTemplate of the control itself. The best practice is to use an external resource dictionary that contains a style that changes various properties and also, if needed, the ControlTemplate.

The problem there is that there is no way to partially change the control template. I mean, yeah, I could think of a few ways, but in the end is the same thing: you need to replace the control template completely. And now you have two ... err.. actually three problems.

First, there are ways of getting the default control template, with all the functionality (we are talking about one, two or even more pages of XAML) and change only what you want. It's not trivial, but it can be done, either by copying it from the published sources (like the Windows SDK or the Expression Blend SystemThemes folder) or by using a utility like ShowMeTheTemplate.

Second, there is the issue of control templates differing depending on the Windows theme. And therefore one must either accept that the application will only look one way for every theme and Windows operating system, or provide templates for all the themes available (there are 6 defaults and a generic fallback theme).

Now, there are many tutorials about how to do that, basically just create a Themes folder, change AssemblyInfo.cs to

[assembly: ThemeInfo(
ResourceDictionaryLocation.SourceAssembly, //where theme specific resource dictionaries are located
ResourceDictionaryLocation.SourceAssembly //where the generic resource dictionary is located

, copy the xaml files (with certain names) there and change them as you see fit. There is a catch, though! This will only work on your custom controls. Default controls already have a template in the operating system theme, so you need to do one extra thing in order to overwrite them, and that is to write the following in the a parent control Resources block:

<ResourceDictionary Source="{ThemeDictionary [LibraryOrApplicationNamespace]}" />

otherwise it will NOT work.

You can get the same result by adding this to the static constructor of the control, provided you have access to the sources:

DefaultStyleKeyProperty.OverrideMetadata(typeof([MyControlClass]), new FrameworkPropertyMetadata(typeof(MyControlClass)));

One thing you also need to be aware of is that Visual Studio caches the themes. If you change them, especially if you do it outside visual Studio, you need to force a Rebuild of the project.

I've decided to write this entry before I could actually master these tools because I don't think I will afterwards (I'd be too old to type). So here it goes:

  1. ReSharper - yes! I will probably need a ReSharper blog tag. This thing is good for everything! Its XAML smart intellisense is a gem, as well as the various options you get when writing WPF code or XAML
  2. Snoop - this is a very small tool that acts like a WPF FireBug. It can select an element, show properties, even change some of them
  3. Mole Visualizer - this is a Visual Studio debug visualizer, one that allows very detailed exploration of debugged objects, especially WPF elements
  4. XAML Power Tools - a Visual Studio addon, it allows a lot of stuff, like automatically generate the view from a model, extracting a style from a control, etc
  5. KaXaml - a tool that works like a XamlPad, but has more options. You basically use it as a poor man's Blend; and it's very light
  6. XamlPad - this is a Microsoft tool. Unfortunately, to use it you need to download the entire Windows SDK for Windows Server 2008 and .NET Framework 3.5, which is 1.5Gb in size
  7. Pistachio - this is a Visual Studio project resource browser. Give it the project and you can see the brushes, the style, the templates, the usages
  8. Expression Blend - the de facto Microsoft tool for editing XAML and working with design stuff. Not only it is not free, but it is also buggy. Unfortunately, I have a hunch I will have to use it in the near future to work with WPF styles
  9. ShowMeTheTemplate - Small application that explores the WPF default templates for various controls

All of the tools above, except ReSharper and Blend are free to use.

So I wasted 15 minutes on trying to make a converter work within a TemplateBinding. Even if there is no error returned, the converter is never called. Funny, no?

I was trying to bind a property to the value of a property of the parent UserControl in WPF. When you google for it you get something pretty interesting: give a name to the user control right inside the user control XAML, then reference it with ElementName.

What I found after hours of torment was that this doesn't always work. I guess it only works up to the first item container in the logical tree and then stops. So that when I tried to use a property ImageSource of the user control in a Menu.Icon it failed!

My solution looks pretty ugly, but it does work in all cases!

<Image Source="{Binding RelativeSource={RelativeSource FindAncestor,AncestorType={x:Type Controls:MyUserControl}},Path=MainMenuImageSource}"
Width="16" Height="16"></Image>

In other words: find the ancestor of the type of your user control and use it as the RelativeSource of the binding.

Update: When I had more time to thing I realised that a MultiBinding needs a Converter, but a simple Binding also has a Converter and I guess that is what I should have used. I will update the post when I get to work on Monday.

I started to build the prototype of a control and I hit a wall where WPF binding was concerned.

For example: I wanted to bind my control to a collection of Items which could be Groups, Sections or Items. Groups have more Sections and Items. Sections have more Items, but they should be displayed as a non clickable section with its Item children under it. Everything in a menu.

At first I used an XML data source, which allowed me to use XPath to select all the Items in a Group, all the Sections and all the Items in the Section like this: XPath="Item|Section|Section/Item". However, when switching to an object schema, the normal Path syntax was too restrictive to allow for this. Even with a MultiBinding, I could find no Path syntax in which to select children of a certain type and their children. However! MultiBinding uses a Converter to usually merge two or more collections together. I used it to get the children and their own children! So forget XAML in this case, just use code:

public class SectionHeaderConverter:IMultiValueConverter
public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
List<ToolBarItem> list = new List<ToolBarItem>();
foreach (IEnumerable<ToolBarItem> collection in values)
foreach (ToolBarItem element in collection)
var toolBarSectionHeader = element as ToolBarSectionHeader;
if (toolBarSectionHeader != null)
foreach (var item in toolBarSectionHeader.Items)
return list;

public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
throw new NotImplementedException();

This converter was then used in the XAML as the Converter for the MultiBinding:

<MultiBinding Converter="{StaticResource SectionHeaderConverter}">
<Binding Path="Items"/>

Now, that fixed one issue, but how can I now make the different MenuItems to
  1. have different looks depending on type/attributes
  2. behave differently depending on type/attributes
but selectively, keeping the default style and datatemplate in other cases? At first, when I used the XML datasource, having an XPath to select the type of the node based on its name was not an option because the XAML XPath implementation does not allow for XPath functions! so I used a StyleSelector for the difference between Sections (unclickable, spanning the whole width of the menu strip) and normal menu items, then a DataTemplateSelector for the difference between Groups and Items. It is also here where I bound the MenuItem Click RoutedEventHandler to an EventHandler in the datasource item class.

ItemsSource="{Binding ElementName=ToolBarCurrent,Path=Items}"
ItemContainerStyleSelector="{StaticResource MenuItemContainerStyleSelector}"
ItemTemplateSelector="{StaticResource MenuItemTemplateStyleSelector}"

I don't know if that is the best way to do it, but suddenly it was like a fog lifted from my eyes and instead of that dreaded XAML I had something I know and understand used in a simple fashion. It is beyond the scope of this post to show how specific implementations of the selectors above work, but there are two issues that I had to fix:
  • Since the styles were resources defined in the resources of the containing Grid, I had to find a way to reference the Grid object from the StyleSelector:
    This is done using the
    ItemsControl ic = ItemsControl.ItemsControlFromItemContainer(container);
    var style = (Style) ic.FindResource("SectionStyle");
  • Since the data templates were resources defined in the resources of the containing Grid, I had to find a way to reference the Grid object from the DataTemplateSelector:
    this seems to be the same problem, but actually the solution was quite different, I used the FindVisualParent helper method like this:
    var ic = Helper.FindVisualParent<Grid>(container);
    The source for it is underneath.

public static TParentItem FindVisualParent<TParentItem>(DependencyObject obj)
where TParentItem : DependencyObject
DependencyObject current = obj;
while (current != null)
var tCurrent = current as TParentItem;
if (tCurrent != null)
return tCurrent;
current = VisualTreeHelper.GetParent(current);
return null;

Also, regarding this particular task, I found a way to display MenuItems grouped by a property in this blog post and at first I used this solution only to find out that this type of grouping only applies to flat DataTemplates. And while it seemed to be working in my first attempts with a HierarchicalDataTemplate, the grouping was only applied to the first level and not to the next.

My conclusion: as in many "magical" technologies, the complexity of a lot of problems is beyond the ability of the technology designers to predict. Therefore the only (and often enough, the best) option is to use your own code.

In Windows Presentation Foundation all resources (like ImageSources or Resource packs) are relative to the namespace of the control. So if you have a folder Images that holds your application icons and you use (in the application XAML) an ImageSource of "Images/MyImage.png" it will work. But as soon as the XAML is moved somewhere in a UserControl in the Controls namespace of a library, the ImageSource becomes invalid. It would only work as "../Images/MyImage.png" or "/Images/MyImage.png", even if the Controls namespace is not a folder and the control is in a library, not in the application that runs it!

This is part of a larger idea, that is Pack URIs. Pack URIs are used by the Open Packaging Conventions and are of the format pack://authority/path.

Long story short, authority can be application:/// or siteoforigin:///. The slashes at the end get escaped as commas in a pack URI so you get to have stuff like pack://application:,,,/ResourceFile.xaml. The path is more tricky: AssemblyShortName[;Version][;PublicKey];component/Path.
Attention at the component keyword. It is NOT a folder, but a keyword that must be there when referencing resources from an external library.

Example: I have the Resources/Images/image.png in a library and I want to use it in the XAML that is in the same library. The image source would be something like pack://application:,,,/libraryNameSpace;component/Resources/Images/image.png. Again look out for the component keyword.

Just yesterday I was struggling with the same issue, only this facette of it seems like a completely different bug. You see, I added this control to the library and everything worked fine EXCEPT the visual designer. It is known that the Visual Studio 2008 WPF designer is not the best possible piece of software, but this was one of those errors you don't know where it comes from.

So, let's take it from the beginning. I had something like
<HierarchicalDataTemplate DataType="{x:Type Code:League}" ItemsSource="{Binding Path=Divisions}">
<TextBlock Text="{Binding Path=Name}"/>
Somewhere in the Window declaration there was a
which is the namespace of the test application for the control in the library.
The application worked, but in the designer an error like "Type reference cannot find public type named 'League'.".

Many people gave the solution to remove the name of the assembly in the namespace declaration. So If I had something like "clr-namespace:MyControls.Desktop.Code;assembly=MyControls" and it was the current assembly, I should just remove it. Well, it wasn't the case here, was it?

In the end I found the solution here. You see, even if the assembly name was not specified, it was implied! And even if it was an application, not a library, it still was an assembly. And the Application name was... something with spaces in it!!

So, again, just go to the Project properties and change the Assembly name to not have spaces!

So, I had just wasted a long time being stupid about a user control, but I had finally fixed everything and I was willing to try it out. Initially I had tested it by directly entering it in XAML, but now I wanted to add it to the toolbox and drag and drop it to the WPF form.

First I got an error like "The following assemblies are installed SDK assemblies but could not be shown in the customize toolbox dialog because they are missing one or more components. Please make sure that all necessary libraries are available:" and then Microsoft.Ink.dll. It didn't seem to do anything bad, but I googled it anyway. It seems that a lot of people had this problem. The only solution was to actually close Visual Studio and then open it again. Other people reported more complicated issues like Visual Studio suddenly closing or showing a lot more libraries and doing it every time. This could help in that case: 363321. Choose Items in Toolbox causes Visual Studio 2008 SP1 to crash.
It also may be linked to the Visual Studio 2008 SDK, which I had recently installed.

Anyway, after that problem was solved, I proceeded on loading my WPF user control library by clicking Choose Items on a new Visual Studio toolbox tab and then browsing the DLL. Boom! "There are no components in 'something.dll' that can be placed on the toolbox.". That is because you must FIRST select the WPF Components tab in the Choose Items dialog, THEN click Browse. If you have Visual Studio 2005 you are out of luck, you don't even have the WPF components tab and the only way to do it is use the XAML editor.