The more I get to know the System.Windows.Markup namespace, the more I like it.  Here’s something I came across today when I implemented a method to walk through a collection and find an element by name.  Because I was populating the collection using XAML, I wanted to name the elements in the collection using x:Name.

As you know, x:Name isn’t actually a property on the element where it gets set, but a “special” property in the x: namespace which can be set on any XAML element.  In other words, even if a class doesn’t have a property called x:Name (or even just Name), you can still set x:Name on it.  

Now x:Name is a useful thing to set because it does some cool things for you.  The most interesting, of course, is that it gives you a variable with the same name that you can write code against.

Now on some elements there actually is a property called Name (notice no x: here).  You’ve probably noticed that setting Name or setting x:Name generally seems to do the same thing.  In other words, if I set plain old Name on an element, I still seem to get all of the magic of x:Name.  Any FrameworkElement, for example, has a Name property that behaves like x:Name.  This is very cool and I wanted to mimic this on the elements in my collection. 

It turns out that doing this is very easy.  All you need to do is define a property  on your custom element (call it what you want, I’m not sure if there are constraints to the type though) and flag it as the “RuntimeNameProperty” using the RuntimeNameProperty class attribute.  Like this:

[RuntimeNameProperty(”Name”)]
public class MyClass
{
    private string _Name;
    public string Name
    {
        get { return _Name; }
        set { _Name = value; }
    }
}

Once you do that, the magic just happens.  Now, whenever I set the Name property on MyClass, I’ll automatically get all of the x:Name xamly goodness.

I thought I had posted this a while ago, but couldn’t find it today when someone asked me about it, so forgive me if this is a repeat.

You may have tried to do this, create a Scrollbar template where the thumb stays a fixed size, and then, like me, given up.  At least that’s what I did the first time I tried it when Karsten and I were working on a demo for MIX last year. 

Though not easily discoverable, it turns out that it is possible to do this.  The trick is in the Track control (a very inner part of both the ScrollBar and Slider templates).  Track has a tight relationship with ScrollViewer and even seeks out the ViewportSize property on a ScrollViewer on its own.  That’s how it knows how to size the Thumb.  If, however, you overrided the value for ViewportSize (on the Track, not the ScrollViewer) to be Double.NaN, then the track will leave the size of the Thumb alone.

In other words, deep in the guts of the ScrollBar template, you have a Track control.  On that Track, you need to do this:

<Track ViewportSize=”{x:Static sys:Double.NaN} …

To get that to work, of course, you need to have mapped the System namespace to the prefix sys.  You can do that like this:

xmlns:sys=”clr-namespace:System;assembly=mscorlib”

Once all that is done, Track will leave the size of the Thumb alone.  At that point, make sure you give the Thumb a size, otherwise it will just disappear.

Here’s a SimpleStyle version of ScrollBar with fixed thumb.

I’m a bit of a color nut, and I was just blown away by Kuler.  It’s an online, community driven color palette creationg and sharing app.  I know, that’s a lot of verbage.  It’s really cool though and could be really inspiring if you’re looking for colors. 

It also feature some pretty sweet design of its own.  My favorite part is the ginormous color swatches.  That being said, it can take a while to figure out how to create palettes of your own.  It’s worth it though.  Once you get the hang of it, it’s great because of their support for some of the classic color theory constructs (triad, complementary, etc.).  Great job Adobe!

They also included a pointer to this great color theory overview.  This is a really good read, especially if color is not intuitive to you–you know who you are.

Lester just posted a private update to XamlPad (the very one that ships with the Widnows SDK) that gives it some very cool new functionality.  Some of this is the standard stuff that you would expect: Kaxaml and notepad style stuff like Find / Replace / Goto.  My favorite feature, howver, is a simple command interpreter that lets you write simple code to interact with objects in your tree on the fly.

If you’ve done any digging into WPF control templates, you’ve likely come across an element or two called “PART_[something].”  These guys are scattered throughout the default control styles and are also widely used in SimpleStyles.  You might be wondering what it means and what it does.

So, here’s the skinny: “PART_” is just a naming convention.  It means that the control expects an element with that name to exist in the template and will be looking for it.  Think of it as a way to flag that element as important and an indication that the name shouldn’t change. The control could be looking for that element for a variety of reasons.  A common example is to add an event handler. 

In fact, Any time the control needs to interact directly with a “part” of its template, the “official” best practice is to use the “PART_” naming convention.  The other part of that best practice, though, is that things should “fail gracefully” when that element isn’t available.  Obviously, some parts matter more than others and a missing part might mean missing functionality, but things shouldn’t blow up (exceptions, etc.). 

This is important for a number of reasons, but especially because it is common for elements to be missing while a template author is mid-authoring.  This is especially true in a tool like Expression Interactive Designer. 

The official manifesto on these kinds of best practices can be found here, although it looks like the updated version with the “PART_” convention hasn’t made its way into the SDK (that may have been my bad).

In the meantime, if you’re authoring templates this should help to clarify things a little.  I don’t think anyone has documented the complete list of “PART_” parts, but I believe they are all represented in SimpleStyles.  Also, if you’re building controls, it would be a great idea to follow this convention whenever possible.

A number of people have requested new or updated versions of samples.  I’ll be post those and some cool new stuff in the next couple of days on the new WPF community site.

Every control in the new version of simple styles takes a depedency on a file called Shared.xaml. This file contains a set of resources (mostly brushes…. err, actually, all brushes) that define all of colors that I use. I was pretty strict about everything in that file and not hardcoding anything. The result of this is that it’s pretty easy to make a new color scheme for simple styles.

To test this out, I took a stab at creating “glassy” version of simple styles. Here’s the updated shared.xaml. It mostly worked. Here you can see some of the original simple styles (on top) and the glassy version (below).

There are a couple of places that I ran into some problems, though. I made the “WindowBackground” color semi-transparent because I wanted TextBox and ListBox to get the glassy feel. The problem is that I use this same color as the background for the popup in Menu and ComboBox. A semi-transparent Menu is pretty tough to use. I also discovered that I had hardcoded some colors in ScrollBar. This will need to fixed in a future version.

To actually use this, you’ll probably have to make a handful of tweaks in the SimpleStyles themselves. I’ll leave that up to you. Overall, though, you could be up and running with this in 10-15 min. The whole thing took me about 45 minutes… not bad for creating a whole new look for Simple Styles.

I just posted a major update of Simple Styles that work with February CTP bits. This was a major rewrite and now includes almost all of the major controls that ship in the box. They’re also a little simpler now.  TabControl, for example, went from hundreds to dozens of lines.  I’ve also taken it upon myself to give SimpleStyles their own tag line, so here it is: SimpleStyles: Simple Looking, Simple Tweaking.  Let me know if you want to write a jingle.  Play around and let me know what you think.

I’ve updated the Shiny Orangy button style to be current with February CTP bits. Get it here.

Sorry that I’ve been pretty silent for the last couple of weeks. I was at PDC for a week and then took a week and a half off to visit my wife’s family in Ithaca. Well, as you can imagine, this meant a lot of flying and I used my time on the plane to build some control styles. The two I’ve made so far turned out pretty nicely, so I’ve posted them for your styling pleasure. So far, I’ve only created two styles: one for Button and one for TabControl, but more should be coming. These work with the September CTP bits (which are the same bits handed out at the PDC).

You can download the styles here.
(more…)