Top wpf Questions

List of Tags
JP Richardson

I'm a C#/Windows Forms programmer with more than 5 years experience. I've been investigating WPF using the MVVM (Model-View-ViewModel) design pattern. I have searched the Internet for tutorials. I have even watched the entirety of Jason Dolinger's awesome video. Although I have found many, I have not found one that takes me from start to finish. What I really want is a tutorial that doesn't assume any previous WPF knowledge.

What are your favorite WPF-MVVM tutorials that helped you to learn?

Answered By: Metro Smurf ( 161)

Your question really seems to be asking 2 questions:

  1. Where are some good tutorials on WPF, assuming I have no previous WPF experience?
  2. Where are some good tutorials on learning MVVM?

Some of these resources may be duplicated in previous answers...

Tutorials on WPF

MVVM Tutorials

Composite WPF (Prism) Resources
Though not exactly what you asked, it is the natural progression with WPF and MVVM.

I am trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.

Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it)

We all know that WPF and Silverlight and Winforms, etc will keep working under windows 8 on at least on Intel system, so please don't tell me that...

Answered By: Pavel Minaev ( 333)

At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.

One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.

Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.

Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.

Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.

It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.

Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI - look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.

WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.

David Schmitt

How do I use RelativeSource with WPF bindings and what are the different use-cases?

Answered By: Abe Heidebrecht ( 247)

If you want to bind to another property on the object:

{Binding Path=PathToProperty, RelativeSource={RelativeSource Self}}

If you want to get a property on an ancestor:

{Binding Path=PathToProperty, RelativeSource={RelativeSource AncestorType={x:Type typeOfAncestor}}}

If you want to get a property on the templated parent (so you can do 2 way bindings in a ControlTemplate)

{Binding Path=PathToProperty, RelativeSource={RelativeSource TemplatedParent}}

or, shorter (this only works for OneWay bindings):

{TemplateBinding Path=PathToProperty}

When implementing the ViewModel in a Model-View-ViewModel architecture WPF application there seem to be two major choices how to make it databindable. I have seen implementations that use DependencyProperty for properties the View is going to bind against and I have seen the ViewModel implementing INotifyPropertyChanged instead. My question is when should I prefer one over the other? Are there any performance differences? Is it really a good idea to give the ViewModel dependencies to WPF? What else do I need to consider when make the design decision?

Answered By: jbe ( 105)

Kent wrote an interesting blog about this topic: View Models: POCOs versus DependencyObjects.

Short summary:

  1. DependencyObjects are not marked as serializable
  2. The DependencyObject class overrides and seals the Equals() and GetHashCode() methods
  3. A DependencyObject has thread affinity – it can only be accessed on the thread on which it was created

I prefer the POCO approach. A base class for PresentationModel (aka ViewModel) which implements INotifyPropertyChanged interface can be found here:


I am developing an application with the MVVM model, but I have reached a point where I need to choose which framework to use.

Among the possible options are:

  • MVVM Toolkit
  • MVVM Foundation
  • WPF Application Framework (WAF)
  • Light MVVM
  • Caliburn
  • Cinch
  • Prism

In your experience, which is better?

Answered By: Pete OHanlon ( 140)

It really depends on what you are trying to achieve, and how much infrastructure you want in place already, plus the ease with which you can find samples that help you out. I'm going to declare an interest here, because I've been actively involved in at least one MVVM framework, and I've had input into others through the WPF Disciples group, so I'm a little bit biased. Saying that, here goes:

Microsofts MVVM Toolkit - this is still very much in the alpha stages. When it was originally released, it took a bit of a savaging from the Disciples because of what it didn't do. Saying that, MS is looking to beef this framework up so it's one to watch - it's just not ready yet.

MVVM Foundation - ah Josh Smith's version of the framework. Josh is one of the daddies of MVVM, and has been a huge advocate and teacher of the pattern. As a result, a lot of what you'll find in other frameworks has Josh's fingerprints all over it. This framework is intended to provide the basics of MVVM, and not to address some of the more esoteric issues. Originally this was intended only for WPF, but people such as Laurent Bugnion and myself have added functionality/projects that mean this will be a Silverlight compatible framework as well.

WAF - no experience of it, so I can't comment on it I'm afraid.

MVVM Light - Laurent Bugnion's take on it, and just updated to version 2. This is a very good framework, but again it's not intended to cover every single aspect of MVVM applications. Given Laurent's background, it has very strong Silverlight and Blendability support in it.

Update Laurent has just informed me that the .NET 3.5 and .NET 4.0 versions are feature compatible. Wau to go Laurent.

Cinch - Sacha Barber's excellent WPF only MVVM framework. This covers more ground than the frameworks I've talked about above. It's an excellent framework, and takes advantage of concepts covered in Bill Kempf's excellent Onyx project. Onyx is intended to complement MVVM frameworks, and adds in functionality that's typically been hard for people to do in MVVM/WPF. Again, originally intended to be WPF only, Onyx has progressed to include SL compatibility - work I am particularly proud to have been involved in.

Prism - Again, I've never used it, but I've heard a lot of good things about it.

Ocean - Karl Shifflett, Program Manager on the Cider team, recently released a fully featured WPF MVVM framework. Again, this is an excellent framework and has lots to recommend it.

The bottom line is, download the different frameworks take a look at them and work out which one fits most intuitively with the way you think and with your requirements. If you think that you might want to support Silverlight from the same codebase then the WPF only frameworks should be discounted.

Isak Savo

When using resources such as brushes, templates and styles in WPF, they can be specified either as StaticResources

<Rectangle Fill="{StaticResource MyBrush}" />

or as a DynamicResource

<ItemsControl ItemTemplate="{DynamicResource MyItemTemplate}"  />

Most of the times (always?), only one works and the other will throw exception during runtime. But I'd like to know why:

  • What is the main difference. Like memory or performance implications
  • Are there rules in WPF like "brushes are always static" and "templates are always dynamic" etc.?

I assume the choice between Static vs Dynamic isn't as arbitrary as it seems... but I fail to see the pattern.

Answered By: Phil Wright ( 157)

A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored.

A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.

Drew Noakes

The title says it all. Sometimes it seems that the Name and x:Name attributes are interchangeable.

So, what are the definitive differences between them, and when is it preferable to use one over the other?

Are there any performance or memory implications to using them the wrong way?

EDIT Responses so far suggest that using x:Name all the time works fine, but I still want to know what the difference is. Microsoft put these two attributes into the very first release of WPF, so there must be some sensible explanation.

Answered By: chuckj ( 158)

There really is only one name in XAML, the x:Name. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name by using the RuntimeNamePropertyAttribute on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.

The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement introduces a Name property.

In general, a class does not need to store the name for x:Name to be useable. All x:Name means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.

So, why are there two ways to do the same thing? The simple answer because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together my marking the Name property as an alias of x:Name.

In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.

Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.


Using C# and WPF under .net (rather than WindowsForms or console), what is the correct way to create an application that can only be run as a single instance? I know it has something to do with some mythical thing called a mutex, rarely can I find someone that bothers to stop and explain what one of these are.

The code needs to also inform the already running instance that the user tried to start a second one, and maybe also pass any command line arguments if any existed.

Answered By: Matt Davis ( 105)

Here is a very good article regarding the Mutex solution. The approach described by the article is advantageous for two reasons.

First, it does not require a dependency on the Microsoft.VisualBasic assembly. If my project already had a dependency on that assembly, I would probably advocate using the approach shown in the accepted answer. But as it is, I do not use the Microsoft.VisualBasic assembly, and I'd rather not add an unnecessary dependency to my project.

Second, the article shows how to bring the existing instance of the application to the foreground when the user tries to start another instance. That's a very nice touch that the other Mutex solutions described here do not address.