design-time writer’s block

Today I released a small pet project of mine on Codeplex, called AttachedBindings. It’s a library for Silverlight which attempts to bridge the feature gap of Bindings between Silverlight and WPF. It contains an attached behavior that implements a form of ElementName Binding between two FrameworkElements.

Here is a simple example, which shows a Calendar control that changes opacity when Slider.Value changes.

<e:Calendar ab:AttachedBinding.Binding=
    "TargetProperty=Opacity, ElementName=OpacitySlider, Path=Value"/>
<Slider x:Name="OpacitySlider" Minimum="0" Maximum="1"
    SmallChange="0.1" LargeChange="0.1" Value="1.0"/>

Enjoy!

Disclaimer : Thanks go to Neil Mosafi, his ElementNameBinder was first on the scene. I reasoned an Attached Behavior with a custom TypeConverter would be easier to use, and I was able to make some optimizations along the way.

So I just read Robby’s fantastic and informative post discussing the state of 3d support in silverlight and I had one nitpick clarification I wanted to point out. Some context; in his post he discusses markup in silverlight within the “‘Real’ 3D Frameworks” part, stating

Unfortunately, Silverlight doesn’t yet have the parser extensibility required to make these APIs markup friendly. For now, at least, the 3D API may be compatible with WPF in code, but there’s not a good markup story.

This isn’t exactly true. Silverlight supports custom TypeConverters, which would allow the xaml parser to convert custom type markup to objects. This is just a case of Kit3D hasn’t yet ported those over, for things like Vector3D using a Vector3DConverter.

The xaml story for silverlight is pretty strong, over all. In addition to TypeConverters, you can use XmlnsDefinition in silverlight, so that you can map several namespaces to a single schema Uri providing a more natural usage of namespaces in your xaml. The only thing that silverlight is really lacking is MarkupExtensions, which incidentally I think will be added in a future release, based on the fact that the MS.Internal.IMarkupExtension interface exists in System.Windows.dll.

[Updated 8.5.2008]
Hey Robby, Turns out I was wrong about XmlnsDefinitions. Yes the attributes exist in silverlight 2, but the XamlParser does not respect them. As Mark has informed me, this is a feature that will be added after Silverlight 2 RTM. On the plus side, TypeConverters definitely work.