Tag: .NET

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a new series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t.

Well, we’re getting close. Part 1 showed that the standard controls in WPF were all you needed to make autocomplete happen. Part 2 started us on the road to packaging it up into a reusable component; Part 3 went neck deep into advanced WPF territory to finish the hard part of our implementation. In this final segment, I’ll cover some neat features of WPF that we can take advantage of to make our AutoComplete TextBox even better.

There is one more thing to discuss: improvements over the Win32 implementation. The code has a little more in it than what I’ve shown. When creating this, I based it on the ComboBox in the Windows Run dialog. What’s the point of doing this in WPF if we don’t take advantage of the new platform? I touched on Templates earlier when I replaced the TextBox template with my own in Part 3. The ListBox (more accurately, the ItemsControl) allows us to template the UI for our data objects with DataTemplates. What if we exposed that so we could change the look of the autocomplete list? Say we wanted to add an image for each item, as well as text.

Also, what if I wanted to index on more than one property? Currently, my implementation works on the ToString() method for each object, keeping the instances in the list that correspond to what’s typed in the TextBox. Wouldn’t it be cool if we could arbitrarily choose the properties to index on? Then we could get the same behaviour as the Outlook addressee textboxes in the New Mail Window.

I’ll deal with first one, um, first, since it’s the easiest: just expose a DependencyProperty or another Attached property of type DataTemplate. In the PropertyChanged event handler, assign it to the ListBox.ItemTemplate property which you can see in the code.

The second is just a matter of adding a new Dependency Property and changing the CollectionViewSource.Filter event handler like so:

private void CollectionViewSource_Filter(object sender, FilterEventArgs e)
{
   AutoCompleteFilterPathCollection filterPaths = GetAutoCompleteFilterProperty();
   if (filterPaths != null)
   {
      Type t = e.Item.GetType();
      foreach (string autoCompleteProperty in filterPaths)
      {
         PropertyInfo info = t.GetProperty(autoCompleteProperty);
         object value = info.GetValue(e.Item, null);
         if (TextBoxStartsWith(value))
         {
            e.Accepted = true;
            return;
         }
      }
      e.Accepted = false;
   }
   else
   {
      e.Accepted = TextBoxStartsWith(e.Item);
   }
}

where AutoCompleteFilterPathCollection is a custom Collection<string> class with a TypeConverter applied so that we can write the list of properties in a property attribute as a comma-separated list in XAML thusly:

<TextBox ac:AutoComplete.FilterPath="LastName,Email"
         ac:AutoComplete.Source="{Binding Source={StaticResource people}}" 
         Name="textBox2"></TextBox>

Then we can get an autocomplete textbox that behaves similar to the Outlook To address bar, that indexes on Name and Email. Easy.

API Design Aside: Now we have three Dependency Properties; the client XAML is looking a little cluttered. At this point I may want to make my own AutoComplete object and have one attached DependencyProperty of that type that you set on the TextBox. This has the advantage of enabling sharing AutoComplete data across many controls. But, on the other hand, that design sacrifices the ease of use. There are a couple of ways to present this to the developer, now, is my point. I’ll leave that as an exercise for the reader.

The final thing I wanted to do was show how simple it is to enable this to work on ComboBoxes. It requires just a quick refactoring to parameterize a few things when we set the control in the AutoComplete instance, as shown in Part 3, which I reproduce here:

private static void OnSourcePropertyChanged(DependencyObject d, 
                                    DependencyPropertyChangedEventArgs e)
{
   AutoComplete ac = new AutoComplete();
   ac.TextBox = (Control)d;
   ac.ViewSource.Source = e.NewValue;
   d.SetValue(AutoCompleteInstancePropertyKey, ac);
}

internal Control TextBox
 {
    set 
    {
       control = value;
       Style s = (Style)this["autoCompleteTextBoxStyle"];
       viewSource = (CollectionViewSource)control.GetViewSource(s);
       viewSource.Filter += CollectionViewSource_Filter;
       value.SetValue(Control.StyleProperty, this["autoCompleteTextBoxStyle"]);
       value.ApplyTemplate();
       autoCompletePopup = (Popup) value.Template.FindName("autoCompletePopup", value);
       value.AddHandler(System.Windows.Controls.TextBox.TextChangedEvent, 
                                new TextChangedEventHandler(textBox1_TextChanged));
       value.LostFocus += textBox1_LostFocus;
       value.PreviewKeyUp += textBox1_PreviewKeyUp;
    }
 }

As you see, I’ve typed the TextBox property to Control so I can set this to a ComboBox as well, but there are a few things we’ll have to move into a custom type. For starters, the Style for ComboBox is different than TextBox, so we’ll have to repeat the steps that we took when extracting the TextBox style, namely (deep breath) open XamlPadX, extract the ComboBox style, put it in my ResourceDictionary, add the ListBox control to the visual tree and add the CollectionViewSource to the Style’s Resources.

Once we’ve done that, we want to change the TextBox property above. The two things that we need to change are the hard-coded resource key, "autoCompleteTextBoxStyle"; and we have to parameterize where the CollectionViewSource comes from which you can tell from the two Styles. You can see the code for all the details, but the TextBox property (which I should rename) now looks like this:

internal Control TextBox
{
   set 
   {
      control = AutoCompleteControl.Create(value);
      Style s = (Style)this[control.StyleKey];
      viewSource = control.GetViewSource(s);
      viewSource.Filter += CollectionViewSource_Filter;
      value.SetValue(Control.StyleProperty, this[control.StyleKey]);
      value.ApplyTemplate();
      autoCompletePopup = (Popup) value.Template.FindName("autoCompletePopup", value);
      value.AddHandler(System.Windows.Controls.TextBox.TextChangedEvent, 
                                    new TextChangedEventHandler(textBox1_TextChanged));
      value.LostFocus += textBox1_LostFocus;
      value.PreviewKeyUp += textBox1_PreviewKeyUp;
   }
}

My parameterization class is slightly more complicated because of other methods in the AutoComplete class. One thing that is truly magic in this case is setting the TextChangedEvent handler on the ComboBox. Notice that I’m adding a handler to the TextBox.TextChangedEvent. Look at the ComboBox API, and you won’t see a TextChangedEvent! Yet it works just as you’d expect it to. That’s some magic that I don’t understand. Magic or no, the ease with which we’ve introduced autocomplete for ComboBox can’t go unnoticed. Note also that the ComboBox’s own Items are unaffected by autocomplete (you can set them both to the same data source, though).

Phew! As you’ve seen over this massive edition of the Missing .NET, creating behaviour in WPF needn’t involve custom controls, but it does require a solid understanding of the underlying design concepts of WPF. There is definitely more we can do with this AutoComplete stuff as well. Hopefully, I’ve shown you the start of what’s possible.

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a new series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t.

In Part 1, I roughed in my AutoComplete Textbox with standard WPF controls. In Part 2, I decided to deploy this as an attached property but ran into some trouble with inserting my WPF controls into an control’s visual tree. In this part below, I show how I solved the visual tree problem using ControlTemplates.

Charles Petzold has an example of creating a ControlTemplate in code in his Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation (Pro – Developer). It involves creating a nested set of factories: truly painful. So I quickly abandoned it as a tenable method for replacing the ControlTemplate. That meant a XAML solution for writing out the ControlTemplate.

But a XAML solution creates its own problems, especially since I’ll have to access the objects created by the template in code (the CollectionViewSource for one, and another control that has yet to make its appearance in this saga). Again, my ignorance with these advanced WPF concepts forced a solution that may not be the best one: I decided to use a ResourceDictionary.

The ResourceDictionary is damn near ubiquitous in WPF. Both FrameworkElement and FrameworkContentElement have a Resources property that allow you to store arbitrary .NET objects, so every control has a Resources property. This is often where styles or data sources are stored, but it can be any .NET object. You can also create your own ResourceDictionary as a standalone class, typically as App-level resources or as a Theme. The cool thing about ResourceDictionary, if you associate it with a class is that you can combine XAML and code like you do in a Window class. Since I’ve already got my AutoComplete class started, what I did was add a ResourceDictionary to my project and used the Class attribute (in the XAML namespace) to associate it with my AutoComplete class.

Now I have to write my own ControlTemplate for TextBox that will allow me to stick my ListBox to it. I could start from scratch, but then I’d have to recreate all the behaviour of the TextBox, including borders, colours, mouse over behaviour, etc, and I want to get this done. I have XamlPadX, so why not pull out the default TextBox style and manipulate it? It’s got the standard look and everything. So that’s what I do: stick that in my ResourceDictionary and change the template to add the ListBox, like this:

<ControlTemplate TargetType="TextBoxBase">
    <StackPanel>
        <mwt:ListBoxChrome Name="Bd">
            <ScrollViewer Name="PART_ContentHost" />
        </mwt:ListBoxChrome>
        <Popup x:Name="autoCompletePopup" 
               Placement="Bottom" 
               PlacementTarget="{Binding ElementName=Bd}"
               StaysOpen="False"
               AllowsTransparency="True">
            <ListBox x:Name="AutoCompleteListBox"
                     ItemsSource="{Binding Source={StaticResource viewSource}}" />
        </Popup>
    </StackPanel>
    <ControlTemplate.Triggers ...>
</ControlTemplate>

This is the relevant piece where I set the Template property on the Control. You can view the entire ResourceDictionary here (Or Download the source). It differs from the standard one in a few places: 1) The StackPanel that contains the TextBox and 2) the Popup containing the ListBox with the name AutoCompleteListBox. Why use the Popup? I’ll leave that as an exercise for the reader. 🙂 Note the ListBoxChrome element with the ScrollViewer inside it. The ListBoxChrome element resides in the Presenation.Aero assembly. Not listed is the Style.Resources property where I add the CollectionViewSource with the Filter event handled.

The methods for handling the CollectionViewSource.Filter and the TextBox.TextChanged events remain the same, I just have to move them to the AutoComplete class and hook them up to the TextBox when it’s passed to me in the OnSourcePropertyChanged event handler when my attached property changes, about which I mentioned earlier in Part 2. I did this with a private, read-only DependencyProperty that creates an AutoComplete instance to associate with the TextBox as the code below shows:

private static void OnSourcePropertyChanged(DependencyObject d, 
                                    DependencyPropertyChangedEventArgs e)
{
   AutoComplete ac = new AutoComplete();
   ac.TextBox = (Control)d;
   ac.ViewSource.Source = e.NewValue;
   d.SetValue(AutoCompleteInstancePropertyKey, ac);
}

internal Control TextBox
 {
    set 
    {
       control = value;
       Style s = (Style)this["autoCompleteTextBoxStyle"];
       viewSource = (CollectionViewSource)control.GetViewSource(s);
       viewSource.Filter += CollectionViewSource_Filter;
       value.SetValue(Control.StyleProperty, this["autoCompleteTextBoxStyle"]);
       value.ApplyTemplate();
       autoCompletePopup = (Popup) value.Template.FindName("autoCompletePopup", value);
       value.AddHandler(System.Windows.Controls.TextBox.TextChangedEvent, 
                                new TextChangedEventHandler(textBox1_TextChanged));
       value.LostFocus += textBox1_LostFocus;
       value.PreviewKeyUp += textBox1_PreviewKeyUp;
    }
 }

In the AutoComplete.TextBox setter is where I set the TextBox’s Style to my style and grab my CollectionViewSource and a reference to the Popup.

That’s essentially it. We’ve created an autocomplete TextBox in WPF! But what’s the point when you don’t take advantage of the new tech? Next time I’ll explain a couple of improvements we can make to the AutoComplete TextBox and show that adding support from ComboBox is really straightforward.

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a new series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t.

In Part 1 last time, I started creating an AutoComplete TextBox in WPF using only the controls given to us by Microsoft and the concepts of WPF. I showed how you can quickly get the meat of the problem solved using a custom ICollectionView that filters based on the text in the TextBox. In this part, I’ll discuss what’s needed to make it reusable.

Reusa-ma-bility

Alright. So we have a pretty good idea of what’s required, how are we going to package this up to be reused elsewhere? Right now, my implementation is good for the window that I implemented it in. I could make a new control, and add this logic to it, but I already said at the outset that that wasn’t going to happen.

What I decided to use was an attached property. The guidance on using Attached Properties was what finally sold me. See, I also want to use this on ComboBoxes eventually, but ComboBox and TextBox, which both have a Text property, don’t have a common ancestor past Control. One of the scenarios that the docs describe, but don’t provide an example of is wanting to have a property on different, unrelated parts of the control hierarchy. I don’t know why Microsoft can’t provide an example, but I can: the TextSearch class defines two attached properties with this scenario in mind. (Seriously, the docs for .NET 1.1 were awesome. What the hell happened to msdn?)

OK, so I’m going to use an attached property. What that looks like is the following:

public sealed partial class AutoComplete
{
  public static readonly DependencyProperty SourceProperty;

  static AutoComplete()
  {
     SourceProperty = DependencyProperty.RegisterAttached("Source",
                        typeof (object), typeof (AutoComplete),
                        new FrameworkPropertyMetadata(null,OnSourcePropertyChanged));     
  }

  public static object GetSource(DependencyObject o)
  {
     return o.GetValue(SourceProperty);
  }

  public static void SetSource(DependencyObject o, object value)
  {
     o.SetValue(SourceProperty, value);
  }
}

This is pretty standard stuff that you can find in the docs. The one piece that’s missing in that snippet is the event handler method OnSourcePropertyChanged that’s declared in the call to DependencyProperty.RegisterAttached. I’ll get to that in Part 3.

What this allows is I can use this on any DependencyObject, like so:

<StackPanel >
    <TextBox Name="textBox1" 
         local:AutoComplete.Source="{Binding Source={StaticResource people}}"
         VerticalAlignment="Top" 
         HorizontalAlignment="Stretch" 
         TextChanged="textBox1_TextChanged" />    
</StackPanel>

where local is my declared namespace for my assembly (Visual Studio does this for you).

Awesome. I can put this on a ComboBox now, or anything else that allows text input. Now we have an auto-completing TextBox. Your welcome.

Yes, you have a question? There’s some parts missing? Like what? Oh, right the ListBox, it’s not there anymore.

A Look-less Autocomplete TextBox

I’ve already solved the hard problem of getting the List to show up when the user types something; I just need to make that work on any TextBox. The trouble is, I’m manipulating the visual tree, which, to my belated discovery, is really hard to do in code after the TextBox is created. Turns what I want to do is create a ControlTemplate that contains my ListBox and replace the TextBox’s Template with my own.

One of the key concepts in WPF is what the folks at Microsoft call "look-less controls". The canonical example is the button. There are a bajillion — at my last count — samples of making buttons look different than the standard Windows button in WPF. They do this by manipulating either the Content property of the button, or its ControlTemplate. Either way, you still have a button that can be clicked, but you’ve changed the look of the button. All WPF controls act like this, more or less, to some degree: I was asked to make a ListBox turn into a TabControl and that’s non-trivial, nigh impossible, even though they are related in the control hierarchy.

Another example is the ComboBox. I mentioned in the first edition of The Missing .NET that the traditional Win32 ComboBox is made up of three controls: a button, a listbox, and a textbox. Well, so is the WPF ComboBox! Only, the WPF is a little more explicit about it, and more flexible. The place where this is done is the Control.Template dependency property; it’s a dependency property hanging off Control that lets you set the visual tree of your control. The standard controls manipulate this property in their default Style. One tool you want in your WPF developer toolbox is something that will deconstruct the default Styles of the standard controls; I use XamlpadX. Bombing around the styles should give you an understanding of how they work.

Deconstructing the ComboBox in XamlPadX, sure enough, we see the TextBox, the ToggleButton and the ItemsControl, of which ListBox is a descendent.

We’re getting into some seriously advanced, yet fundamental WPF stuff here, which is a little beyond the scope of this blog post, at least if I wanted to finish quickly. If you’re interested in learning about Templates and Styles, Google can be big help; if you’d prefer to learn offline, then any of the WPF books will be quite helpful. Start small, and work your way up. Learning how templates and styles work is definitely worth the effort.

So the only way to stick my ListBox into the visual tree is to replace the ControlTemplate of the TextBox.

This is where the internets came up short for me and I went out on my own. I have no idea if my solution is a good idea. It seems to work, and work well, but I don’t know enough about WPF to tell if this will work in every situation. Every solution creates its own problems and I ran into a few while solving this one.

OK, so what did I do?

You’ll have to wait ’til next time. 🙂