WPF – where art thou’ my tools? Waiting for a pod of Orcas and other imperfections.

Andreas Erben — Sun, 11 Mar 2007 22:53:00 GMT

When working with Windows Presentation Foundation (WPF) you quickly run into limitations of current tool support and also encounter unexpected limitations.
This may or not change with the release of "Orcas", however, at the time of the initial post, Orcas is not available.

This post will be updated whenever I stumble across something that simply bothers me.

To work with WPF your usual set of tools will be

Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP and potentially for the visually oriented folks: Expression Blend and Expression Design.

The typical developer typically will root for a solid support inside of Visual Studio 2005 rather than for a program from the Expression series.

Intellisense won't recognize valid XAML patterns because the XSD does not seem to be complete.

For example the DataTemplate MSDN code will not be supported by IntelliSense:

Here DataTemplate and all childnodes of DataTemplate will not be recognized.

Other limitations include the visual designer that will just fail to load if you reference a namespace in the same assembly of the XAML included.

Take the start of the XAML of the ListBoxEvent sample from the SDK:

Because of the xmlns:src="clr-namespace:ListBoxEvent", the visual designer will tell you: "Whoops! Visual Studio has encountered an error reading the designer file. The errors are shown in the task list. Make appropriate changes to the designer file and then click on the Design button to try again."

In some cases also the method of then using a class of the referenced namespace as an ObjectType="x:Type src:MyTypeHere" in an ObjectDataProvider will not work and during the compile an error message will be raised that the class cannot be found. I have not been able to create a reasonably small example for that yet, though.

Worse: Even a commonly found way of displaying an image will mess up the designer:

Other pain-points:

XAML does not support generics yet.

There are folks who extend XAML, see the reference post by Mike Hillberg: Limited generics support in Xaml

The usual method is to use wrapper classes that inherit from a Generic (and usually have to fill the Generic in the constructor).

public class myColors : ObservableCollection<string>
{
     public myColors()
     {
          Add("LightBlue");
          Add("Pink");
          Add("Red");
          Add("Purple");
          Add("Blue");
          Add("Green");
      }
}

Note that this will also work with List<string> In a "one way" type of behaviour.

However you could always use Generics from the C# code if you do something like:

MyListBox.ItemSource=MyGenericListObject;
It is really just an issue about how XAML is getting parsed and not of WPF itself.
I do not understand why it does not seem to be permissible to use the syntax (or something similar) that you encounter in comparable scenarios like:
System.Collections.Generic.List'1[[System.String]]
or
System.Collections.Generic.Dictionary`2[[System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Int32, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]

(At least I have not been able to get it working)

Andreas Erben's posts : WPF

WPF – where art thou’ my tools? Waiting for a pod of Orcas and other imperfections.