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

Question

I want to launch a new WPF application. The new user interface in WPF needs to manage the DataGridView and PropertyGrid . But it looks like these two controls will not exist in WPF, and I want to host these two controls using WindowsFormsHost .

However, if I do this, are there any restrictions that anyone sees with this approach?

Answer 1

The main limitation is that you lose all the powerful WPF features: Data binding , ControlTemplates and DataTemplates , infinite size, scaling / rotation, Opacity , Attached Properties , to name a few. That's a lot to give up! You will have to program these controls using the old tedious and error-prone WinForms methods, and again cope with all those limitations that you released years ago.

DataGridView

NET Framework 3.5 sp1 has a DataGrid that can do the job, and for this there are several third-party controls, for example, one of Xceed. Using a WPF-based grid allows for complete data binding, patterning and styling within the grid, which would not be possible if you were using the DataGridView WinForms.

PropertyGrid

The reason WPF does not come with PropertyGrid is because it is easy to recreate it with what WPF already provides: a simple list will do, properly formatted, with just a few lines of code.

The beauty of using the WPF PropertyGrid implementation is that you can use templates to represent the properties you are editing, and most importantly, you can add new property editors by simply expressing them in XAML with multiple bindings. For example, some properties in one of our property grids are set using sliders, and these are just about five XAML lines for this to happen.

Here are a few examples that illustrate key concepts for implementing 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’s very quick and easy to reproduce the entire look of the PropertyGrid with just a few XAML lines: just use a CategoryBox ItemTemplate , which consists of a DockPanel containing a fixed Width TextBlock associated with the property name, and ContentPresenter to print the property editor.

Answer 2

Firstly, there are third-party property grids and data grids for WPF, and they will usually support additional WPF styling features and are more idiomatically complemented by WPF applications. Thus, you do not need to return to WinForms and probably should not, unless third-party or management tools are an option.

If you need to go back to WinForms, the main limitation you need to be aware of is the "airspace rule": you cannot have WinForms and WPF controls overlapping each other. Plus, of course, WinForms controls cannot participate in WPF data binding and should be considered using the old-skool procedural code, although you can encapsulate them in user controls to get around this. In addition, if you try to pretend to be visual effects, then they may not work too well with WinForms controls: the airspace rule can bite you very much if you are doing translations or animations in the immediate vicinity of the WinForms control. But for visually simple applications, they should work fine.

Answer 3

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