WPF Samples in our documentation


Currently, when you click on a link to download one of the Windows Presentation Foundation Samples, you go to the Windows SDK .NET Framework 3.0 Samples page, which allows you to download all the samples at once. The problem is that when you are looking at an individual sample topic, there is no way for you to know where each sample is in the download you just installed.  We are currently working on a way for users to download individual samples from their respective topics, which will allow you to determine the location of the sample yourself.  In the meantime, here is a file that lists all the WPF samples and their locations. 



About Us



We are the Windows Presentation Foundation SDK writers and editors.

SampleTopicsWithInstallPaths.txt


Comments (5)

  1. evansdmw says:

    How about more C++/CLI samples? Maybe a working app like a NotePad app?

  2. MSDN Archive says:

    What a great idea!  I’ve cross posted this information on my blog as well http://blogs.msdn.com/karinm/archive/2007/01/20/finding-wpf-samples-in-the-sdk-docs.aspx

    Karin Meier

    Samples PM, Windows SDK

  3. joewood says:

    What about hosting the samples as running XBAPs in an IFRAME with the source in its own frame.  Online only of course.

  4. wcsdkteam says:

    joewood,

    On the XBAP front, I can answer.

    Your suggestion is a good one, although the idea of using XBAPs only works for a subset of our samples.

    The first reason is that WPF enables users to build a wide variety of user experiences, which our samples try to be representative of. Consequently, some of our samples have user experiences that don’t translate well into the XBAP style of user experience, such as standalone Windows applications. See Build a Great Experience with Windows Presentation Foundation [1].

    The second reason is one of security. XBAPS run in a partial trust security sandbox that restricts functionality to a subset of the features provided by WPF. Since our samples demonstrate the complete range of WPF functionality, some of them won’t run as XBAPs where they exceed the security restrictions enforced by the security sandbox. See WPF Partial Trust Security [2].

    Still, your idea is a good one and we are always considering new ways to deliver our sample content to our customers in ways that are compelling, easy to use, and, if possible, use the technology they are demonstrating to do so.

    [1] http://msdn.microsoft.com/msdnmag/issues/06/10/AppFundamentals/default.aspx

    [2] http://msdn2.microsoft.com/en-gb/library/aa970910.aspx

  5. wcsdkteam says:

    >> How about more C++/CLI samples? Maybe a working app like a NotePad app?

    Also a good idea. But there are some issues with CLI samples too. In particular, building for CLI doesn’t have updated MSBUILD targets. Because of that, the compiler doesn’t know how to compile XAML as a page in a CLI project. Probably 75% or more of the samples we put in the SDK use XAML in some form, even if just for the appdef.

    There’s two ways around the issue: 1) Compile the XAML into a library using a different language like C#, and then reference the library 2) Don’t use XAML and build everything up from Main(). You can see the former approach in some of the interop samples. Taking either approach for converting the other existing samples to CLI versions  is a pretty time intensive port, and we haven’t gotten very far on that.