Limitations of using .NET 2.0 (Windows Forms) controls in WPF?

I want to start 开发者_如何学运维a new application on WPF. The new User interface in WPF needs DataGridView control and PropertyGrid Control. But it looks like that these two controls won't exist in WPF and I want to host these two controls using WindowsFormsHost.

However, if I do that, is there any limitation anybody forsee with this approach?

The main limitation is that you loose all the powerful features of WPF: Data binding, ControlTemplates and DataTemplates, Infinite sizing, Zooms/Rotations, Opacity, Attached Properties, just to name a few. That's a lot to give up! You'll have to program these controls using the old tedious and error-prone WinForms techniques, and deal again with all those limitations you freed yourself from years ago.

DataGridView

NET Framework 3.5 sp1 has a DataGrid that may do the job, and there are several of third-party controls for this such as the one from Xceed. Using a WPF-based grid allows complete data binding, templating and styling inside the grid which would not be possible if you use WinForms' DataGridView.

PropertyGrid

The reason WPF doesn't come with a PropertyGrid is that it is so easy to recreate using what WPF already gives you: A simple listbox will do, properly styled, with only a few lines of code-behind.

The beauty in using a WPF PropertyGrid implementation is that you can use templates to present the properties you are editing, and most importantly you can add new property editors by just expressing them in XAML with a few bindings. For example, some of the properties in one of our property grids are set with sliders, and it was only about five lines of XAML to get that to happen.

Here is some code illustrating the key concepts behind implementing a PropertyGrid in WPF:

public class PropertyGrid
{
  ...
  public static readonly DependencyProperty SelectedObjectProperty = ...
  {
    PropertyChangedCallback = (obj, e) =>
    {
      PropertyItems =
        from pi in SelectedObject.GetType().GetProperties()
        select new PropertyGridItem { Object = SelectedObject, PropertyInfo = pi };
    }
  }
}

public class PropertyInfo
{
  public object Object;
  public PropertyInfo PropertyInfo;
  public object Value
  {
    get { return PropertyInfo.GetValue(Object); }
    set { PropertyInfo.SetValue(Object, value); }
  }
  public string Category
  {
    get
    {
      return (
        from attrib in PropertyInfo.GetCustomAttributes().OfType<CategoryAttribute>()
        select attrib.Name
      ).FirstOrDefault();
    }
  }
}

With this it is very quick and easy to replicate the entire look and feel of PropertyGrid with a few lines of XAML: Just use a ListBox with grouping by Category, and an ItemTemplate that consists of a DockPanel containing a fixed width TextBlock bound to the property name and a ContentPresenter to print the property editor.

First off, there are third party property grids and data grids for WPF, and these will typically support the additional styling capabilities of WPF and fit in more idiomatically with WPF applications. So you don't need to drop back to WinForms, and probably shouldn't unless third party or toolkit controls really aren't an option.

If you do have to drop back to WinForms, the main limitation to be aware of is the "airspace rule": you can't have WinForms and WPF controls overlapping each other. Plus of course WinForms controls can't participate in WPF data binding and will have to be addressed using old-skool procedural code, though you could encapsulate them in user controls to work around this. Also, if you're trying to do fancy visual effects then they may not work too well with the WinForms controls: the airspace rule is likely to bite you hard if you are doing transforms or animations in the vicinity of a WinForms control. But for visually simple applications they should work okay.

There's a Datagrid control in the WPF Toolkit. There's also a third party PropertyGrid control on CodePlex as well (under the very permissive MS-PL license).