# Thursday, June 11, 2009

A month or so ago I posted on a solution for simulating “default button” semantics in a Silverlight app, meaning that if you are entering text in a text box and you hit the enter key, the “default button” for the “page” should be pressed.  Very natural for form entry, etc. 

An issue came up (discovered by John Papa) with the solution in a Prism app, because my solution depends on being able to find the “default” button in the visual tree using the FindName method.  That means that you have to be high enough up the visual tree to find the button, since it only works “down” the tree.  In a Prism app, it’s not necessarily clear where “high enough” might be.  Plus, because the solution requires unique names, and Prism modules may have nothing to do with one another, they may have duplicate names, etc.

Here’s a revision to the solution that doesn’t require unique names, and doesn’t require any static references that might interfere with proper garbage collection…

First, a new object called DefaultButtonHub that keeps track of the relationship between text boxes and buttons.  It also exposes an Attached Property that takes a DefaultButtonHub reference so we can hook up text boxes and buttons to the “hub” in XAML.

public class DefaultButtonHub
   ButtonAutomationPeer peer = null;

   private void Attach(DependencyObject source)
       if (source is Button)
           peer = new ButtonAutomationPeer(source as Button);
       else if (source is TextBox)
           TextBox tb = source as TextBox;
           tb.KeyUp += OnKeyUp;
       else if (source is PasswordBox)
           PasswordBox pb = source as PasswordBox;
           pb.KeyUp += OnKeyUp;

   private void OnKeyUp(object sender, KeyEventArgs arg)
       if(arg.Key == Key.Enter)
           if (peer != null)

   public static DefaultButtonHub GetDefaultHub(DependencyObject obj)
       return (DefaultButtonHub)obj.GetValue(DefaultHubProperty);

   public static void SetDefaultHub(DependencyObject obj, DefaultButtonHub value)
       obj.SetValue(DefaultHubProperty, value);

   // Using a DependencyProperty as the backing store for DefaultHub.  This enables animation, styling, binding, etc...
   public static readonly DependencyProperty DefaultHubProperty =
       DependencyProperty.RegisterAttached("DefaultHub", typeof(DefaultButtonHub), typeof(DefaultButtonHub), new PropertyMetadata(OnHubAttach));

   private static void OnHubAttach(DependencyObject source, DependencyPropertyChangedEventArgs prop)
       DefaultButtonHub hub = prop.NewValue as DefaultButtonHub;


Basically we’re expecting that both the text boxes and the button will register themselves with the “hub”.  If it’s a button that’s being registered, we wrap it in a ButtonAutomationPeer so we can “press” it later.  If it’s a text box, we hook up a KeyUp handler that will “press” the button if it’s there.  The requirement in the XAML is only marginally heavier than in my previous solution…we have to add a resource of type DefaultButtonHub, and point the button and text boxes at it using the {StaticResource} markup extension.

<UserControl x:Class="DefaultButton.Page"
    Width="400" Height="300">
        <my:DefaultButtonHub x:Key="defaultHub"/>
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBox x:Name="theText" Grid.Row="0"
                 my:DefaultButtonHub.DefaultHub="{StaticResource defaultHub}"/>
        <Button x:Name="theButton" Grid.Row="1" Content="Default"
                Click="theButton_Click" my:DefaultButtonHub.DefaultHub="{StaticResource defaultHub}"/>

Note that the new DefaultHub attached property is applied to both the text box and the button, each pointing the the single resource.  This way everything gets wired up property, there isn’t any problem with name resolution (aside from the usual resource name scoping) and everything will get cleaned up if the form needs to be GC’d.