Question

Providing design-time data for DataContext is easy with use of d:DataContext but what about control properties referenced with {TemplateBinding} or {RelativeSource TemplatedParent} from Style.Template ?

Should I just populate control with sample data inside constructor/Loaded event when DesignerProperties.GetIsInDesignMode(this) returns true ?
(Can’t do this since it would break normal design experience).

What about third party-controls that I can’t modify ?

Answer 1

For my own controls I usually do something like:

<Style x:Key="FooStyle>
  <Setter Property="Template>
    <Setter.Value>
      <ControlTemplate TargetType="FooControl">
        <Grid d:DataContext="{d:DesignInstance FooDesignTimeData, IsDesignTimeCreatable=True}">
          ... guts of control template go here ...
        </Grid>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>

Where “FooDesignTimeData” is a class that provides design time data in the appropriate form (implementing the interface from your runtime view model is a good practice here).

I don’t see why this wouldn’t work for a 3rd party control as well. You might not even have to retemplate the control — you might be able to get away by just specifying the 3rd party control inside of your style and giving it a design time data context as specified above, but I haven’t tried that scenario. I assume you’re going to all this trouble because you’re forced to use a control that does not have a great design time experience (such as by providing a Vendor.Controls.Design.dll or Vendor.Controls.Expression.Design.dll file).

To work with the TemplateBindings, I don’t have a great solution. Usually I create a test page that displays my control and allows me to switch templates around. During integration you’ll have an extra view (either within your app or as a separate app) that allows you to create and manipulate instances of the control as necessary. The GoToStateAction targeted trigger action from the Blend SDK is often useful here. For example, create a button for each visual state and then use the Click even to trigger a transition to a particular state. Thus you can easily test all of your states plus transitions while bound to test data. Hacky and not really design time data, but it works.