At the center is a rough custom Behavior that is able to share the visual state of controls that are bound to the same data object. Once the behavior was functional, I simply needed to add the behavior to two Buttons, bind the buttons to the same data, and wire an event to trigger the state change.

<Button MouseEnter="enterHandler" MouseLeave="leaveHandler">
  <i:Interaction.Behaviors>
    <local:SharedVisualStateBehavior Source="{Binding}" />
  </i:Interaction.Behaviors>
</Button>

private void enterHandler(object sender, MouseEventArgs e)
{
  SharedVisualStateBehavior.GoToSharedState(
    (Control)sender, "MouseOver");
}
private void leaveHandler(object sender, MouseEventArgs e)
{
  SharedVisualStateBehavior.GoToSharedState(
    (Control)sender, "Normal");
}

Because of the need to call a static method to actually make use of it, meaning it’s not selfcontained, it doesn’t really qualify as a Behavior.  The ideal SharedVSM would be able to take input in the form of VisualState parameters and possibly a trigger, in order to notify the shared controls of state changes.  It’s a work in progress.

Thanks to Kuler for the theme, Josh Smith for ObserveableObject from MVVM Foundation, and Pete Blois for BindingListener from Expression Samples.

Downloads
Silverlight 3 Dev Tools – Web Installer
Expression Blend 3
Deep Zoom Composer
Silverlight Toolkit
Expression Blend Samples

Noteworthy Sites
Birmingham Museums & Art Gallery
Thirteen23’s TED Player
IdentityMine
Microsoft
Silverlight.net

Blend
Silverlight 3 Runtime
Silverlight 3 Tools for Visual Studio 2008 SP1
SDK

Looking forward to exploring the new features and changes.

To illustrate the mechanics of Attached Behaviors, a topic that I had been reviewing with my customer, I decided to implement a working RadioButtonGroup as one. Simply use the attached property in place of RadioButton.GroupName, and the behavior takes care of the rest.

<ItemsControl ItemsSource="{Binding DataCollection}">
  <ItemsControl.ItemsPanel>
    <ItemsPanelTemplate>
      <StackPanel Orientation="Horizontal" />
    </ItemsPanelTemplate>
  </ItemsControl.ItemsPanel>
  <ItemsControl.ItemTemplate>
    <DataTemplate>
      <RadioButton Content="{Binding Name}"
                   b:RadioButtonGroup.Name="1"/>
    </DataTemplate>
  </ItemsControl.ItemTemplate>
</ItemsControl>

One interesting detail about my implementation: It can be used with ToggleButtons to achieve RadioButton-like behavior.

The solution source is available here. Feedback welcome.

Side note: Using reflector, I noticed that although RadioButton has all the necessary plumbing to group arbitrary radio buttons (and that code is remarkably similar to how a standard attachedbehavior is implemented), it relied on the “Logical Tree”, FrameworkElement.Parent, to scope group names to a common root node. One side effect of using ItemsControl is that the ContentPresenters used to show an item’s DataTemplate are severed from their parents. Parent is always null. This attached behavior doesn’t use that, and in fact it does not scope the group Names at all, so be sure to choose unique names.

Enjoy!

Contest entrants are limited to 10kilobytes of source code and resource files, so like many others, I was constantly budgeting features, making lots of trade off decisions. It was a very enjoyable exercise, because I ended up cutting all my grandiose ideas like explanatory tooltips, sprite animations for the plants, keyboard input, background music, and lots of nice-to-have game mechanics like power ups and penalties, all of which would’ve been way over budget.

My thanks go out to Adam Kinney and crew for putting the contest together and making that weekend much longer and more enjoyable.

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.

To resolve some of this, IdentityMine has set up some good quality videos on a Vimeo channel, which includes our official Reel.  Below is the Surface Promo. Special thanks to Kurt for setting this up!

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.

From the KB Article:

This update improves stability, media streaming, and the auto-update component. This update also improves support for Mozilla Firefox 3.

I’m still hopeful that Silverlight 2 RTM will have a Trigger construct of some kind. But I’m convinced ElementName bindings, Data Template Selectors, and Markup Extensions won’t come until 2.5 or 3.