I’ve been busy on my Silverlight test control and it’s been more fun than I’d expected and it’s actually been a lot easier than I’d expected, too.  So what I’ve been doing is delving into some of the more internal differences to extend what I’d originally planned further.

From a layout perspective, Silverlight 3 is very similar to what I would do in WPF, but it’s much more basic.  You can do many of the same things, but with Sl, it’s pretty scaled down.  By this I mean that WPF is a richer framework and handles some of the details that you otherwise have to do manually in Silverlight.

One thing I’ve noticed is that Silverlight is very lean with its overloaded constructors.  I’m not complaining, it’s an observation.  I’ll give a real example.

In WPF, I could make a rotate transformation like this:

  child.RenderTransform = new RotateTransform((angle * 180 / Math.PI));

The problem  with doing that in Silverlight is that RotateTransform only has the default constructor.  Fortunately, C# 3 included Object Initializers, so the alternate syntax I have to use is completely painless:

  child.RenderTransform = new RotateTransform()
       { Angle = (angle * 180 / Math.PI) };

How awesome is that?

So you still have the benefit of a lighter footprint without the overloaded constructors (which are just get/set anyway in this case), but still painlessly instantiate and initialize the object.

There needs to be a word of caution to newer programmers.  Don’t assume that you can universally bypass all overloaded constructers using Object Initialization as I’ve done above.  While a significant number of such constructors are nothing more than get/set convenience mechanisms, this is not the case every time.

Object Initialization is easier to read than a parameterized, overloaded constructor.  Just don’t forget that constructors can (and often) do more than just initialize properties.

Know your code!

Popularity: 7% [?]

We are technical people in the digital age.  We have more websites, videos, and blogs than you can shake a stick at and yet there’s something about that big heavy tome in your hands.  We like books.  Sure, you can get books on Kindle and read them that way, but it’s not the same.  Regardless, there are quite a few books on WPF and they all have their strengths and weaknesses.  Some completely gloss over certain aspects, while others do likewise with completely different topics.  There are different approaches and even gimmicks, like color (there, I said it.  And I’ll cover that one later.)

The first book I’d like to cover (pun fully intended) in my WPF On-Your-Shelf series is Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation, by Charles Petzold, published by Microsoft Press

A=C+M (as I’ll be calling it) was one of the first major books on WPF, released over 3 years ago.  The philosophy in this book remains unique, even today, best described by the author himself:

I have been writing programs for Windows since 1985, and the WPF is the most exciting development in Windows programming that I’ve experienced. But because it supports two very different programming interfaces, the WPF has also presented great challenges for me in writing this book. After giving the matter much thought, I decided that every WPF programmer should have a solid foundation in writing WPF applications entirely in code. For that reason, Part I of this book shows you how to write complete WPF programs using C#.

Several features of the WPF required enhancements to .NET properties and events, and it’s important to understand these enhancements, particularly when you’re working with XAML. For this reason, I have devoted chapters in Part I specifically to the new concepts of dependency properties and routed input events.

Part II of this book focuses on XAML. I show how to create small XAML-only applications and also how to combine XAML with C# code in creating larger, more sophisticated applications. One of the first jobs I take on in Part II is to create a programming tool called XAML Cruncher that has helped me a lot in learning XAML, and which I hope will help you as well. Because XAML is used primarily to create the visuals of an application, most of the graphics coverage in this book is found in Part II.

In the long run, most of the XAML that gets written in this world will probably be generated by interactive designers and other programming tools. I’m sure that you will eventually use these designers and tools yourself to facilitate the development of your applications. However, I think it’s vital for every WPF programmer to be able to write XAML “manually,” and that’s what I show you how to do in this book.

Even now, I can find no book that takes this approach, which is unfortunate.  Petzold expertly demonstrates that WPF and XAML are not synonymous and then immediately teaches you how to use XAML.  It’s this separation of concerns that makes the book so brilliant.  Every other book on WPF I’ve read (and I’ve read most of them) focuses almost exclusively on the “how” with just a passing overview as to the “what”.  Granted, there are some excellent books that do cover both procedural code (almost always C#, unfortunately for VB programmers) and declarative XAML, only A=C+M treats them as what I would call “windows to the framework” and not the framework itself.

It’s important, even crucial to remember (as I’ve said before) that WPF is not the language.  This book not only remembers it, it’s written around that very concept.

Let me give you a personal example to illustrate what I mean.

I recently interviewed with a very interesting company for a VB.Net/ASP.Net/WinForms and my primary language is C#. Granted, I have VB but it’s not what most of my contracts have required.  Because of the .Net Framework and BCL, I was able to honestly tell them that I can still do the job because most of what differentiates the two is “syntactic sugar” (yes, I know there are some real differences, but those are minor except for XML Literals and one or two others).  It is the framework that makes .Net powerful and likewise it is the fact that WPF is a framework and foundation (and NOT a language or platform) that make it so powerful.  Charles Petzold absolutely nails that concept and drives it home by devoting half the book to creating WPF with procedural code.

The end result is that you come away from reading the A=C+M not only with a greater understanding of WPF, but a better “internalization” of what WPF actually is.  By doing so much in C#, you internally begin to understand how WPF can be done in any language that can use the .Net Framework.  This includes F#, IronRuby, and so on.  You understand that you’re writing for WPF not in WPF.

As you can undoubtedly gather, I’m very much impressed by this book and it remains to this day one of my favorites.  I believe it is an essential read for anyone who truly desires to be the best WPF developer he or she can be.

Popularity: 13% [?]