Before we move on to WF I want to mention a few more WPF resources and give some other directions for you to pursue in your learning of this pillar.  With the release of .NET 3.0 in December, there has been a lot more activity on the web.  Here are a few cool things to check out:

Dominoken

The British Library

Cool 3D Stuff

Good Text Info

The New York Times

Over the last couple of months I have covered what I believe to be many of the most important features in WPF, however I have only barely scratched the surface of what is possible.  There is much more to the framework and I wanted to give a few terms to research and help guide in future learning.  Here are some things you are likely to come in contact with when working on a typical WPF app:

RoutedEvents, Commands, Document Controls, New Printing Model (1 + 2), Adorners, Localization, Bitmap Effects, Geometry.

You can also read this chapter online for an explanation of some key concepts.

WPF is a very powerful framework for building UI.  My hat goes off to the team that built it.  I truly believe it is the best UI framework to date, on any platform.  Since it is only a version one, it still has room to grow quite a bit.  I wanted to conclude this post with a few thoughts on what I would like to see in future versions, if there are any MS guys reading this:

• We need a set of Common Dialog Boxes that have a look and feel that is consistent with WPF.
• WPF Databinding is awesome and is one of my favorite features.  Upon using Reflector, I discovered that is makes extensive use of reflection (no big surprise there).  I would recommend that the WPF team research using fast property setters/getters and LCG for future versions.  I don’t know if this is feasible or would reasonably improve performance, but it is worth looking into.
• We need more common controls.  The important ones that are missing are:  DatePicker, Calendar, Masked Textbox, DataGrid and PropertyGrid.  I would also like to see some more advanced components, such as a window docking system similar to the one in Blend (you’ve already got the source code, why not include it?)
• On the whole, I would like to see better 3D performance.  We need more material types and support for pixel shaders to do next gen stuff.  I like the add-ons for 2D on 3D, so just add those to the SDK.
• When it comes to XBAPs, we need support for WCF minimum and hopefully WF as well.  I expect the WPF team to gradually move more and more WPF features into the XBAP realm as time passes.

And now a big note on WPF/e:

WPF/e is obviously in its early stages, but I still want to make some things clear to any MS folks who have an influence on the first version.  We NEED C# support if you want the product to be usable at all.  Whether MS wants to admit it or not, WPF/e is direct competition for Flash and will be compared as such.  Therefore, if I am going to convince any client to use it, I have to be able to give a compelling argument for using it over Flash.  This is difficult since many clients (who are not tech savvy) know what Flash is and are not likely to know anything about WPF/e.  Additionally, if the only language for use with WPF/e is JavaScript, you are going to have a hard time convincing developers to use it.  In addition to C# support, I feel we need Controls, Panels, and custom controls as a minimum.  We also need a way to communicate with the server other than using JavaScript callbacks.  WCF would be optimum, but I would accept .asmx as a reasonable compromise.  (Remember that Flash has ActionScript, Remoting, Web Service support and Communications Server).  I can only hope that the goal is to gradually bring all of the XBAP functionality over to WPF/e and eventually completely merge the two technologies.  To that effect, why even bother with WPF/e at all?  Why not work with Novell to build the XBAP functionality on top of the already stable Mono project, thus enabling XBAPs to run on Windows, Mac and Linux?

 NEXT POST: WF Intro