is the Visibility attribute of the Field element the only way to control visibility of a of a column. My object whose collection is used as DataContext has 20 properties yet I want to display only 5 of them in a grid. I don't want to define 20 field elements and set the visiblity of 15 of them to false.
I'm trying to remember how the auto amtchup logic works for choosing the "correct" field layout. I would like to think that if you define fields for a subset of the exposed properties, it would match things up for you. In other words, if you defined just two fields (FullName and Phone) to represent a list of contact objects, wouldn't that work just fine?
If not, you can make your desired field layout (subset of fields) and then programmatically assign that layout to the record in the AssigningFieldLayoutToItem event of the grid.
This is a quote from the documentation;
A FieldLayout defines the Fields (columns) contained in a particular DataRecord. When a DataRecord is created, the FieldLayouts collection is searched for an existing FieldLayout whose Fields match the DataItem's properties. If a FieldLayout is found, it is associated with the DataRecord; if it is not found, a new FieldLayout is created. When a new FieldLayout is created, the FieldLayoutInitializing and FieldLayoutInitialized events are raised.
Whis means that if a fieldLayout for a DataRecord is not found and new one is created and the Field Layout events are generated. Does it mean that I would have to set the Visibility=false in the FieldLayoutInitializing handler to prevent it from displaying?
Again, you can programmatically assign the field layout that you want to use. I have done this and it works fine. In fact, I don't like the auto-logic, because when things go wrong, you get no notice. Countless times I've seen empty grids because of a mispelled field name that preventing auto-mapping. I've never seen a field layout automatically created and used. I've seen empty grids. If you manually assign the layout in the event, and something's wrong with that layout (a field name for which there is no corresponding property on the dc) an exception will be thrown. No more painful guesswork.
The whole point of XAML is to seperate visuals from implementation. I shouldn't have to do it programmatically. I discovered an attribute, AutoGenerateFields on FieldLayoutSettings, that allows for controling the default generation of fields but it also seems to prevent hierarchical date from being displayed. Why?
Using code-behind files is NOT mixing UI and implementation. Code behind files are married to the xaml files and there is no reason to not take advantage of them. Everything that can be done in xaml can be done in c#, but not everything that can be done in c# can be done in xaml.
If you disable auto generate, then you need to create the desired field layout. If you want hierachical data to be displayed, then you need to create fields to represent the child data. For instance, if you have a Person object and that object has a Contacts property (List<>) that you want as a sub level in your grid, simply include a field definition to correspond to the Contacts property. Then create another field layout for the Contacts record type. If you're binding to a DataView, then the magic field could be a relationship key.