Bindings are a major part of WPF, and a big part of what makes it quick to create user interfaces in. They can be a little wordy and hard to debug sometimes, but overall they are extremely useful. Hopefully, after today's tutorial, you will find them even more useful - because today we are going to talk about building validation rules right into your bindings. Yup, you heard right - bindings in WPF have built in support for validation, and a number of the common controls have built in ways for displaying validation errors.

Almost every control in WPF uses a control template to define how it displays itself and its contents. In fact, you can override the control template on every built-in control to make it appear and act exactly like you want. Rather than overriding an existing template, however, this tutorial is going to demonstrate how to build a custom content control and use a control template to define how it looks.

WPF comes with a large number of built in controls, but from the beginning it has lacked something that many application developers find extremely important - a DataGrid. You can use the ListView to create something approximating a DataGrid (I've talked about it in a couple different tutorials), but it is a lot of work and not particularly straightforward. Thankfully, Microsoft realizes how important a full-featured DataGrid is - and how you probably don't want to wait for the next version of WPF to be able to use one. This is where the WPF Toolkit comes in. The WPF Toolkit is "a collection of WPF features and components that are being made available outside of the normal .NET Framework ship cycle" which to me translates as "handy new controls I don't have to wait for".

Isn't it really annoying when WPF binding errors fail silently? The application compiles, the application runs, but nothing is working - all because of a silly typo in a binding somewhere. And then, once you realize it is a binding error (which is not always obvious), you have to drudge through the debug output trying to find that one line that says "System.Windows.Data Error ....". Even worse than that is the subtle binding error where the app still works, but maybe the text on some label isn't updating right, and you don't even notice the bug until weeks later.

So here's the problem - say you have a WPF TextBlock with some text (with automatic ellipsing turned on) and you want to know if the text is actually ellipsed at the moment. Sounds simple, right? Unfortunately, there are no properties or methods that you can call to check - well, no public properties or methods, that is. So this makes a simple question into a much harder answer.

We have taken a look at printing in WPF twice before here at SOTC - first with a simple tutorial on just getting something printed, and then a more complex one on pagination. Today we are not going to focus much on the printing side of things, but more on the printer side. For example, how do you get a list of the printers available on the system? Or their capabilities? If you need the answers to those questions, then this is the tutorial for you.

Reading the title, you are probably even wondering why this even deserves a tutorial. Disabling the ability to drag selected text out of a TextBox? That has got to just be a flag somewhere, right? That is what I thought, and it turns out I was quite wrong.

One WPF control that we haven't taken a look at here on SOTC is the TreeView. Well, no more! Today we are going to rectify that, as we build an application that not only uses the TreeView, but also dynamically loads data into it on demand. We are going to cover a couple other new topics as well, including HierarchicalDataTemplates and CompositeCollections.

The ScrollViewer in WPF is pretty handy (and quite flexible) - especially when compared to what you had to work with in WinForms (ScrollableControl). 98% of the time, I can make the ScrollViewer do what I need it to for the given situation. Those other 2 percent, though, can get kind of hairy. Fortunately, WPF provides the IScrollInfo interface - which is what we will be talking about today.

Routed events in WPF let you do all sorts of crazy (and very handy) things. The fact that you can preview events on the way down the visual tree, as well as hook them as they bubble back up opens up a whole world of possibilities that would have been nothing but pain back in WinForms. But I'm not here today to wax poetic on routed events, I'm here to talk about some of the lesser known functionality of the WPF event system - namely Class Handlers.