I’ve gotten many question about design time data and how you can work with it. The default templates are for many a tiny bit complicated, and if you look at most of the examples out there for design time data ther are often just modified versions of the code in the template.

So here is a very simple example created from scratch that will hopefully give you a better idea how design time data works, or at least help you have something visual to work with when you bare working with the design so you don’t have to run the application each time you’ve made a change in the design to see how it actually looks.

To add design time data you need to set the datacontext for the ‘fake data’, now this can be done many different ways, so this is just one way to do it. Here I’ve set the ‘real’ datacontext to the belonging codebehind file, and the designtime data to a class called DesignTimeData. mc:Ignorable=”d” is a way to tell the app to ignore d-prefix attributes during runtime.
Don’t forget to import the namespace where the dasign time data is, as you see by local=”using:…. in this example.

EDIT: This example is for windows store apps, but you can just as well use this for a Windows Phone App, just remember that the namespaces aren’t the same

Windows Store Apps: xmlns:local=”clr-namespace:Your_App”

Windows Phone: xmlns:local=”using:Your_App”

So with d:Datacontext you set the fake data. If you only want to bind to a particular property on that design time class, you can set Binding MySubViewProprty and of course change the name to the actual name. Source tells us where to get the data, and Type tells us what kind of data this is- the type and the last boolean specifies that the design instance is created from our own type

Then you set up your bindings for the elements as usual.

To set up the design time data you just need to make sure the properties the elements expect to bind to exist, and that they are populated in the constructor.

Excellent post…why can’t Microsoft’s documentation and examples be this clear? For a relative noob like myself this is exactly the information I need. I can’t wait to try this out on a few of my apps…I think this will save me a lot of time when I am tweaking my layouts.

As always, you’ve put together another great tutorial! Your sample is so much clearer than any of the MS provided ones.

I did run into one hitch, however. I’m developing on Windows Phone 8, and for some reason I kept getting an error stating that DesignTimeData did not appear in my namespace (this is from my MainPage.xaml).

Apparently I needed to use this:

xmlns:local=”clr-namespace:PhoneApp2″

The key point here is the “CLR-”

I’m not sure of why it required that, but once I had that in place, it all worked fine. Figured I would save someone else the grief!

yeah- namespaces differ between those two platforms- it’s one of the (many) breaking changes between the platforms.
Windows phone: xmlns:local=”clr-namespace:Your_App” Windows Store Apps: xmlns:local=”using:Your_App”

You can also create design time data by the click of a button in Blend for Windows Phone 8 apps (not Windows Store), I have a separate blog post coming about that.

Sorry for the double-post, I just replied on an older post of yours about this same issue.

My issue with binding design time data to the CollectionViewSource. I saw a great example of this in action on a channel 9 video (http://channel9.msdn.com/Events/Build/2012/3-006) but no source code and I could not determine what I have been doing wrong.

On question is do I need to bind this to an XML data source? that would make me a sad panda…

I can bind just find to an ObservableCollection at design time.
I can see data just fine at run time using an CollectionViewSource
I can’t get design time data to show using a CollectionViewSource

I really like this approach but absolutely could not get it to work with my CollectionViewSource. I found one blog post that said CollectionViewSource will still require an d:Source attribute even with the page-level DataContext design-time override you provided. And here I was hoping I found a clean approach and could avoid d:Source attributes in the remaining Xaml on the page. Ah well it was worth a shot.