Look at the XAML sample in the original MDSN documentation on
System.Windows.Controls.GridView
:
http://msdn.microsoft.com/en-us/library/system.windows.controls.gridview%28v=vs.110%29.aspx[
^].
You need to use the XML element
GridViewColumn
with the attribute
DisplayMemberBinding
(again, see that XAML sample). Your
inpData
should be assigned to the property
ItemsSource
of your control, during runtime. In your case, for
toClass
(bad name! it violates Microsoft naming condition and is weird: using the word "class" in the name of the class!) the columns would be like this:
<GridView>
<GridViewColumn Header="First Name"
DisplayMemberBinding="{Binding XPath=Inp}" />
<GridViewColumn Header="Last Name"
DisplayMemberBinding="{Binding XPath=Outp}" />
</GridView>
Note that this is enough if you want to represent your data statically. The idea of binding is also to allow UI to handle the changes in data. If you want to change your list during runtime (add/remove/move items), the list is not enough. If you want the UI to respond to such changes, you need to implement the collection supporting the interface
System.Collections.ObjectModel.ObservableCollection<toClass>
:
http://msdn.microsoft.com/en-us/library/ms668604.aspx[
^].
Moreover, if you also need to modify the members of
toClass
the way the changes are handled by the UI, this class should implement the interface
System.ComponentModel.INotifyPropertyChanged
:
http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged%28v=vs.110%29.aspx[
^].
Look at the code sample in the MSDN article referenced above. Unfortunately, this interface is as ugly as everything in
System.ComponentModel
. In this case, you need to keep in sync the string value of the property name returned by the event arguments of the event and the property :
http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.propertychanged%28v=vs.110%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.componentmodel.propertychangedeventhandler%28v=vs.110%29.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.componentmodel.propertychangedeventargs(v=vs.110).aspx[
^].
The XAML code of binding with the
PropertyChanged
can look like this:
<GridViewColumn>
<GridViewColumnHeader ...>
<GridViewColumn.CellTemplate>
<DataTemplate>
<TextBlock Text="{Binding Inp, UpdateSourceTrigger=PropertyChanged}"/>
</DataTemplate>
</GridViewColumn.CellTemplate>
</GridViewColumn>
I assumed that you bind your
Inp
property with some
TextBlock
, its property
Text
. As your
Inp
is not a string, you would need, for example, to have a string property and convert it to double (
double.Parse
) and back. The key here is the string "Inp". It does not have to be the same as the real name of the property, but you need to keep the uniqueness of this string (per collection element class) and keep it in sync with that returned through
System.ComponentModel.PropertyChangedEventArgs
. As I say, this is ugly, but this is how
INotifyPropertyChanged
works, not only with XAML.
[EDIT]
In reply to some follow-up questions:
For naming conventions, you can use FXCop:
http://en.wikipedia.org/wiki/Fxcop[
^],
http://msdn.microsoft.com/en-us/library/bb429476.aspx[
^].
Too bad, FxCop is pretty old, but… First, you can checkup your assemblies with it, including naming conventions. Secondly, the product has all references to formal MSDN naming rules and other documents.
I think that a good amount of of the rules are just stupid, but check up of naming, performance problems, and other looks quite good to me. You can always switch off some checks or write your own rules ("exclusions", actually).
For just documentation of this topic, please start here:
http://msdn.microsoft.com/en-us/library/vstudio/ms229045%28v=vs.100%29.aspx[
^].
As to showing of the arbitrary type in a grid view or a list view, this is a very difficult task, a kind of some top-notch techniques. You should have told about this non-trivial and quite interesting requirement clearly in first place.
This is similar to serialization and Data Contract where any type built according to some rules can be serialized; and the serializing system is totally agnostic to the particular types. The key here is reflection. You need to discover types during runtime via Reflection, figure out what members or events to bind and how, and then build both binding and the instance of the presenting control accordingly. I clearly understand how to do it, but it would be a very serious work. If you are interested, I can explain hot to do it, but only if you ask particular questions. (Otherwise, it would be a matter of a really big article.)
Moreover, if you have many objects, the Reflection performance would be a problem. In this case, you would need to use System.Reflection.Emit (as serialization does), and this is an order of magnitude more difficult than serialization, because it needs good understanding of IL, and the debugging is difficult. In brief, you would need to keep a container of all bound type as they appear during runtime. On the fly, you should generate something like "binding assemblies" and associate with already bound and stored types. When you need to bind some object of the type which is registered in your collection, you need to retrieve one of those dynamically created assemblies and invoke appropriate binding code.
I do understand that it sounds complex and not quite clear, but this is the way to go. If you have some questions about that, you are welcome to ask them, but they might be not easy to answer, just because a lot of work is involved.
—SA