There are already quite a few blogs about working with data in Blend out there. Rather than repeating them I’ll talk about less obvious aspects.

Part 1: drag-and-drop secrets

The best way to learn about data drag-and-drop is to play with it. It is quite intuitive. A word of advise. Pay attention to tooltips. They will tell you what will happen when you drop data. If you did not pay attention to a tooltip and got something you did not expected then undo you last action and drag it again. This time check the tooltip. It will not fix the issue, but at least you’ll know what is going on without looking at XAML. To provide meaningful examples I’ll use BookStore sample data structure as shown below. Besides plain vanilla drag-and-drop you can do Shift+drag-and-drop and Alt+drag-and-drop.

Shift + drag-and-drop will suppress most of the smartness, such as creating a new control and/or auto selecting a property to bind to. Most common effect is that Blend will prompt you to select a control property. This gives you precise control over setting bindings in those cases where Blend fails to read your mind. For example. Drag-drop Address.City. Blend creates a text box and bind data to Text property. Now undo and Shift-drop Address.City. This time Blend prompts you to select a property of LayoutRoot grid. Sometimes Shift-drop appears to have no effect. For example if you drag-drop Books.Title Blend will create a list box of Title‘s. Same will happen if you do Shift-drop. Why? Because by suppressing smartness you’ll end up with a disabled drop operation. If it comes to choose between “do nothing” and “do something” Blend will always choose “do something” option.

Alt + drag-and-drop performs Details mode drop. Blend supports two drop modes, List mode (a.k.a. default or master mode) and Details mode. To switch between them you can click on one of two buttons at the top left of Data pane. Details mode allows you quickly creating “details view” in master-details scenarios.

For example drag-drop Books.Title to create a list box, then switch into Details mode, select Author, ISBN and Price properties, and drop them next to the list box. Blend will create “details” grid with selected properties and set element name binding between the list box and the grid.

Details drop is a relatively rare operation. Once you create details view you can switch back into List mode, drag-drop Title into details grid and Blend will do the right thing (create a new text box and bind it to Title). I personally find myself forgetting to switch between the modes, i.e. forget to click on List or Details buttons. On a next drop I have to stare at a screen for a few seconds trying to understand what is wrong. With Alt-drop I do not need to click on mode buttons and just do my details drop. One nice touch I like in Blend is that it uses different tooltip background colors in List mode versus Details mode. This is helpful to quickly tell what mode you are in without moving focus from mouse cursor to Data pane.

There is something interesting about creating details view. If you drop data on an existing panel (Grid, StackPanel, etc) and that panel has neither DataContext nor d:DataContext properties set then Blend will “reuse” the panel as a container to create details view. Blend will also “reuse” container if it has the right data context, or another way of saying it is that if you just created details view then you can drop into that panel again to add more details fields. Otherwise Blend will create a new grid as a container for details view. So if you do not like grid then create your own panel first and then drop details onto it. Another interesting thing is the difference in creating details view when you drop one data property versus two or more. In case of multiple properties Blend will create label-field pairs as shown above. In case of one property Blend will create just a filed with no label. This is quite practical. If there is only one filed in details view then it does not really matter if you get a label-field pair or just a field. In case of multiple properties you can add them all at once (or in batches) to get label-field pairs. Or you can add them one at a time to get fields only.

You can also use Alt-drop to set design data context. For example I want to create a user control to use it as details view for list of books. Here is one way to do it. First, I create new user control (File –> New Item…, then select UserControl). Then I alt-drop Books onto [UserControl] in Object and Timeline pane. This will set d:DataContext property to collection item Books[0].

Note that I set design data context on user control rather than on its content (LayoutRoot grid). In case you missed this cool feature, you can drag-drop data directly into Object and Timeline pane. This allows you to bind data to “invisible” entities like DataGridColumn (which is not a FrameworkElement, yet available in Object and Timeline pane). With design data context set I can drag-drop book properties – e.g. Title, Author - to create text boxes. And I get my data displayed! What is nice is that it is all driven by design data context, which is non-existent at runtime. Moreover. Once I build my project and use my new control in MainControl.xaml design data context is also out of picture. So I can bind my new user control to list of books to get data from the right data source, which matches my runtime setup.

To summarize, you can use Alt-drop (or Details mode) to either create details view or set design data context. The rules are:
1. If you drop one or more leaf properties (e.g. Title, Author) then Blend will create details view.
2. If you drop complex or collection property (e.g Books, or Books.Revisions, or Address), then Blend will set design data context. You can also use Alt+Shift+drag-and-drop to select a different property. Alt will put you into Details mode while Shift will suppress default property selection logic.

Back to List mode (a.k.a. default mode) drag-and-drop. Collections play essential role in drag-and-drop scenarios. You probably noticed that you cannot drag-drop second-or-deeper level collections because such bindings do not make sense most of the time. For example you cannot drag-drop Books.Revisions (unless you are in Details mode). Said that Blend has robust data context calculation heuristics. For example. Drag-drop Books.Title to create a list box of Title‘s . Then start editing list box item template (right click on list box, Edit Additional Templates –> Edit Generated Items –> Edit Current). Note how Data pane highlights current data context:

Now drag-drop Books.ISBN onto StackPanel, either in Object pane or on the StakPanel border on artbaord (as show below) to create a text box.

Blend figured out that current data context is a collection item Books[0] and made a right decision to create a text box rather than a list box of ISBN’s. Now drag-drop Books.Revisions.Year onto StackPanel. Blend will create a list box of Year’s:

And guess what. You can drill into Year’s list box item template and Blend will correctly detect new data context Books[0].Revisions[0]. In other words you can be many levels deep into template editing and Blend will figure out data context. This is very convenient. However this will nor work if you edit a data template out of context, i.e. if instead of doing Edit Additional Templates –> Edit Generated Items –> Edit Current you go to Resources pane and start editing data template from there. This will cause undesired results in case of data drag-drop. One way to mitigate the issue is to set design data context at the root visual in your template. For example if you have
<DataTemplate x:Key="BooksItemTemplate">
      <StackPanel>
            <TextBlock Text="{Binding Title}"/>
      </StackPanel>
</DataTemplate>

and you use Resources pane to edit the template then you can alt-drop Books onto stack panel to get something like this
<DataTemplate x:Key="BooksItemTemplate">
      <StackPanel d:DataContext="{Binding Source={StaticResource MyBook}}">
            <TextBlock Text="{Binding Title}"/>
      </StackPanel>
</DataTemplate>

Great thing to learn is how Blend decides what control property to bind to by default. Blend does it by looking at DefaultBindingProperty attribute. For example when dropping Books onto combo box Blend picks ItemsSource property because it is marked as a default binding property by ItemsControl. Actually ItemsControl type does not have DefaultBindingProperty. Blend does it instead by adding quite a few attributes to common controls (to improve design experience). However control vendors should add all the necessary attributes if they want better design experience of their controls in Blend. There are a few other interesting attributes which can improve the experience. I will talk about them in a separate article.

Obviously Blend checks control properties for compatibility with data types. For example Blend will not try to bind Price (double) to ItemsControl.ItemsSource (IEnumerable). Blend does some tricks with types analysis to get more practical results:
1. While string is an IEnumerable (i.e. it implements IEnumerable interface) Blend does not bind string data to IEnumerable control properties. For example Address.Street will not match ItemsSource property.
2. Blend allows binding data type to control properties of corresponding Nullable type. For example bool data can be bound to ToggleButton.IsChecked, which is Nullable<bool>.
3. Blend allows binding data type to control properties of “convertible” type. This means that if a control property marked with a type converter attribute (or control property type has a type converter) and the converter can “digest” data type then binding is allowed. For example I can have a custom control and mark MyControl.MyVisibility property with BoolToVisibility converter. Then Blend will allow binding bool data to MyVisibility property. There is one exception to this rule. Blend does match string data with IConvertible control properties (double, bool, int, etc). For example Blend will not match Address.Street data to MyControl.MyWidth (double) property.
4. Blend allows binding IConvertible (“sting like”) data types (double, int, bool) to string control properties. For example Blend will allow binding Price (double) to TextBox.Text.

A control type can have only one default binding property. While it seems to be somewhat restrictive it is not that big of a deal. When looking for a default property to bind to Blend looks at a target control type and all its base types. Thus Blend ends up with a few properties to choose from. For example TextBlock.Text is a default binding property as well as UIElement.IsChecked (in WPF, but not in Silverlight). Thus when dropping data onto TextBlock Blend has two properties to choose from. So bool data will be bound by default to IsChecked property and string data will be bound to Text.

In rare cases Blend will have multiple control properties of the same type. For example when dropping bool data onto check box Blend finds two control properties marked as default ones, ToggleButton.IsChecked and UIElement.IsEnabled. In this case blend will choose IsChecked, i.e. property of the most derived type.

If there is no good default binding property then Blend will try to create new controls on drop. Blend makes executive decisions and does not allow any customization. If you are not happy with created controls then you have to create a control of your choice and then drop data on it. Here is what Blend will create for you:
1. If you drop a collection data property then Blend will create a ListBox. It will also create DataTemplate resource (for ListBox.ItemsTemplate) and fill it with collection item properties of primitive types like string, bool, double, etc. For example if you drop Books Blend will fill in a template with Author, ISBN and Price properties, but will not include Address or any of Address child properties. Interestingly enough there is a way to customize what controls will be created for primitive properties (like Author). However it is extremely hacky and there is no guarantee that Blend will work correctly if you choose to mess around with it. Yet if you are interested then check out content of <Blend install dir>\DataBinding\DataTemplate.xaml.
2. If you select one or more collection item properties then Blend will create a ListBox and fill in DataTemplate with selected properties. For example if you drop Books.Title then only Title will be added to data template. Note that you can select collection item sub properties. For example imagine that Author is a complex type containing FirstName and LastName properties. Then you can select Books.Author.FirstName and Books.Author.LastName and Blend will fill in data template with FirstName and LastName. Note that dropping a collection can either end up binding to a property of an existing control or creating a list box. However dropping collection item property(ies) will always create a list box (or drop will be disabled).
3. If you drop one or more non-collection item primitive type properties then blend will create
  a) CheckBox for bool.
  b) Image for ImageSource.
  c) Text for string, double, int and other IConvertible data types.
Remember <Blend install dir>\DataBinding\DataTemplate.xaml? There are two more files at that location, Master.xaml and Details.xaml. Once again I do not recommend making any changes to these files but looking at them will  not hurt.