Nesting implicit styles in WPF

All I wanted to do was define a style at Page level to control the font size of Label controls, and then define other styles for parts of the page where Label controls need to be further customised.

e.g. set font size to 8pt at the top-level, and for some parts of the page, set each label to a specific width.

I Google-d around and thought the Style BasedOn attribute should do it for me.

Alas, it appeared not to.

But then I noticed a major bug in the VS.NET 2008 XAML designer : it was not properly applying style changes!

If I changed the text in a Label control, the XAML designer would reflect that, but if I changed relevant styles, the XAML designer would often miss it.

And that's where I realised : BasedOn IS the key, it's just that the VS.NET XAML designer is so pathetic that you have to close and re-open any XAML document you are editing in order to see the effect of nested style changes.

And of course, to make matters worse, VS.NET is famous for its idiotically slow load times for XAML files in large projects that contain lots of XAML files. So, hello lots more time being wasted now that we're forced to close and re-open XAML files just to get the designer to refresh properly...

Clarity Consulting wrote a nice little piece showing how to use BasedOn with nested implicit styles. The missing piece of the puzzle is simply the need to close and re-open the XAML designer each time you make a change. Ugggh. But at least it eventually gets to the desired effect...

Convert Adobe Illustrator files to XAML via SVG

There are lots of ways to convert Adobe Illustrator files to XAML, but for my needs, none of them were quite good enough.

The Adobe Illustrator XAML-export-plugin was mucking up some of our line art.

InkScape's built-in XAML support was mucking things up even worse. (I LOVE InkScape, but its XAML support is still not as good as hopefully it will be one day...)

XamlTune was mucking up a few things here and there as well.

Anyhow, I discovered that, for our line art, the main problem with XamlTune was its handling of thick strokes on ellipses. I fixed the XamlTune source code, submitted a patch, and now, voila, XamlTune is converting our line art perfectly! (Or at least, my eye notices no deficiencies.)

Here are the steps I'm taking:

1) Open the Adobe Illustrator file in Adobe Illustrator. (A free 30 day trial is available.)

2) Save a copy as an SVG document. (There are lots of SVG options, but at least for us, the default SVG options work fine.)

3) Use XamlTune to convert from SVG to XAML.

I doubt my patch will be integrated into the main XamlTune source in a hurry, so if you have enough technical nouse, get my patch from the XamlTune CodePlex site and enjoy the benefits. :o)

Your mileage may vary - apparently SVG to XAML conversion is not good at handling gradients, but all our line art is just simple sets of lines, paths and shapes, so that hasn't been a problem for us...

"Cannot locate resource" in VS.NET 2008 when debugging

I downloaded XamlTune - very helpful, but a little buggy. So I turned to the VS.NET 2008 debugger. But every time I tried to run the XamlTune source code, I would get a "Cannot locate resource 'Output.xaml'" error message at runtime during app startup.

I searched and searched and found zillions of people getting the "Cannot locate resource" error message, but nothing solved the problem in this case.

By trial and error, I finally discovered that the assembly name is the culprit in this case.

The XamlTune "solution" contains a DLL called XamlTune and a separate executable by the same name.

XamlTune.dll
XamlTune.exe

In Release mode, this runs fine, and presumably, in previous versions of VS.NET, it ran fine. But in VS.NET 2008 sp1, running in Debug mode, the aforesaid error occurs.

The solution is extremely simple: Change one or other project file so that the assembly names of the two projects differ.

Clearly a bug in the VS.NET or .NET framework implementation, and it certainly wasted hours of my time today, but when you know how to solve it, everything works nicely again...

XAML stroke - inconsistent, but livable if you know the tricks...

I'm using XamlTune to convert SVG to XAML. Ellipses with thick strokes weren't converting correctly. I dug deeper, and discovered that XAML is inconsistent in its treatment of stroke placement.

For paths, the stroke is centred on the path line (as with SVG). But with ellipses and rectangles (and hence circles and squares too), XAML draws the stroke INSIDE the perimeter line. SVG is consistent - the stroke is always centred on the perimeter line.

Anyhow, I had difficulty finding info on this anywhere, so I tested my theory with some practical examples.

In XAML, create an Ellipse with e.g. a 100 pixel diameter.

<Ellipse Width="100" Height="100" Fill="Yellow" />

Then set a very wide stroke:

<Ellipse Width="100" Height="100" Fill="Yellow" StrokeThickness="50" Stroke="Blue" />

Voila! Note that the size of the circle is the same whether there is a stroke or not. Thus, XAML uses an internal stroke for ellipses.

But do the same thing in Inkscape (i.e. in SVG) and the circle gets larger as the stroke gets wider.

Since I found it hard to find anyone else commenting on the same "gotcha", I thought I'd make note of it here...