Tour Part 2 - can you keep the grid instead of a form

<sdk:DataGrid AutoGenerateColumns="True" Name="CustomerDataGrid" ItemsSource="{Binding Customers}" />

<sdk:DataGrid Grid.Row="1" Name="CustomerShipToGrid"

ItemsSource="{Binding ElementName=CustomerDataGrid, Path=CurrentItem.ShipToes }"/>

Suppose …

1.       Your TextBox is bound to the ViewModel.FilterCompany property via an attached property or "behavior" (TBD).

2.       Your ViewModel has a method, “FilterFoo()”, that performs the filtered query; the method code might look like

   var query = Manager.Foo

    .AddFilter(FilterOperation.StartsWith, FilterCompany)

    .AddFilter(FilterOperation.StartsWith, FilterContact)

  // your grid’s ItemSource is bound to ResultList

  Repository.ExecuteFilterQuery(ResultList, query);

3.       “FilterFoo” was mentioned when you attached the TextBox property.

How bad would that be? Is this harder than RIA Services? To my eye it’s both simple and transparent.

The Behavior would be pretty simple. It listens for keystrokes. When the key stroking “stops” (i.e., there have been no new keystrokes after the prescribed delay), it invokes your FilterFoo(). The only trickiness is aggregating key stroke across the several controls that participate in the filtering (e.g., FilterCompany and FilterContact textboxes). You get that when you associate each TextBox with the ViewModel filtering method.

AddFilter (TBD) is an extension method on IQueryable<T> that constructs the Where clause(s). It knows to skip the clause if FilterCompany is empty after trimming. You could add the Ignore list as a third parameter if you needed it.

This is DevForce as you know it. And you can use the Behavior anywhere. When you figure out how to trick out your grid with filter input controls, just attach the Behavior to it.