7

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 ?

Marcin Wisnicki
  • 4,511
  • 4
  • 35
  • 57

1 Answers1

6

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.

Mike Post
  • 6,355
  • 3
  • 38
  • 48
  • As I've said `{Binding}` is easy due to `d:DataContext` but I'm after `{TemplateBinding}`s. – Marcin Wisnicki Jul 09 '12 at 08:04
  • Have you tried doing the above, but assigning the d:DataContext as part of the style? I don't have a great solution for this situation: usually I create a test page that displays my control and allows me to switch the templates around. Hacky, but it works. – Mike Post Jul 09 '12 at 16:21
  • This seems reasonable. Have to try this myself. But you have to change the XAML for a integration version, or can you provide the Binding there, too? – Mare Infinitus Jul 12 '12 at 21:46
  • The control's XAML doesn't change between integration and production. The only difference is 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. – Mike Post Jul 12 '12 at 23:40
  • This approach (test page) works for simple control but fails for more complex ones, for example I was unable to find a way to edit ItemContainerStyle while showing the content displayed in test page. Anyway, I guess there is nothing better and people are either doing it this way or write XAML by hand. If you want your bounty I would prefer a separate answer with your idea of using test page (otherwise I'll mark this one). – Marcin Wisnicki Jul 13 '12 at 15:43
  • Edited to include the test page stuff. – Mike Post Jul 13 '12 at 17:47