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% [?]

I was asked during an interview today how well I could translate my WPF skills to Silverlight.  Naturally, I answered that I would be able to do so very quickly.  I consider that confidence, rather than bravado.  I’ve been writing software for over 20 years and to me, a language or technology is simply a means to an end, which end is the final product.  I’ve been fortunate enough to have been blessed with a talent for software development which has enabled me to work in a very diverse range of environments and platforms.

I’m fond of sayings and one popular saying is “put your money where your mouth is”.  Anyone can say or claim anything, especially in a job interview.  I don’t like being lumped in with the crowd and it’s to my detriment that I haven’t been able to point to a completed applet or application as even a small example that I’ve done it.

So, I’m going to take a very short diversion.  I’m going to put something together in Silverlight 3, just so I can have something as even a small example.  The problem was deciding what to write.  Fortunately, there is a wealth of things on the Internet that I think can be improved.  One of these is the restrictive way that Amazon Associate widgets are created.  It’s bad enough that they’re in Flash, but they have limitations that I simply don’t care for.

So I ask that you bear with me as I briefly step into Silverlight land (briefly, as far as this blog goes, that is) and prove my own concept.

I’ll be sure to post here what I’ve done.

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% [?]

Somewhere along the line, and I’m not motivated enough to research it, menus apparently became bad.  I don’t mean they ever stopped working or became unsuitable for the tasks they are given, but just bad.  I’m talking about bad in the same sense as the BLINK tag, HTML frames, or command lines.

Whether it’s twitter clients:

programming utilities:

Even vertical market licensing exams:

Did I miss a memo or something?

It seems that nearly everyone trying to make new, pretty apps these days are going out of their way to drop one of the most useful and space-efficient interface components out the window so they can be replaced with gradient-rich buttons and tabs and/or shaded, cartoony icons.

Why?

I’ve become convinced that this is happening because we developers like “shiny” and “pretty”.  Oh sure, we’re happy to use gray and dull but we’re even more happy if we can show our bosses and clients that we can do “pretty” as well.  We may not have designer skills, but we can still make things look nice, right?

Unfortunately, this is becoming like the nerd who came to school telling his buddies that his big brother who gets all the girls wears Hai Karate and before you know it, everyone smells like a used car dealership.

So stop it.  There are indeed good use cases to use a button-centric interface.  And I’m certainly not suggesting that the old “menus-only” philosophy is better.  But we need to stop hopping on a certain look-and-feel bandwagon because Microsoft is (rightly) trying to bring designers directly into the process.

So who is driving this?  I can’t say.  I don’t know.  But it’s not the major application developers, at least not at this point.  Look at your browser.  It’s almost guaranteed that your browser has a menu at the top.

Look at Visual Studio.  Menus there, too.  Everywhere you look there are still menus and none of the major application houses are rushing to dump them.

There 2 compelling reasons to keep menus:

1. Users are already familiar with them and know how to use them.  Most applications have them at the top, drop down, etc.  Is it sexy?  Perhaps not, but it’s familiar.  Do you want people to use your applications or admire them.  Can it be both?  Certainly, but only if you don’t take away an expected UI element and with it a significant portion of usability.
2. Menus provide a “when all else fails” location for functionality and users know this.  When you can’t find something on a button, tab, slider, link, or icon you instinctively start looking in menus.  Everyone who’s worked with users has heard at least once (likely thousands) the complaint, “I couldn’t find it in a menu…”

Do we want to make our programs more or less functional?  Whether it’s the X to close, resizing from corners, or even menus at the top, it’s become part of the user experience and unless you want to retrain users, it is in all our best interests to continue with what works and build on it, not throw it away.

Popularity: 50% [?]

We live in an age where product age always seem to require a “hook.”.  Whether it’s Microsoft putting either “Visual” or “MS” in front of every name or the ubiquitous “iCrap” you can’t avoid, it’s refreshing to find an application that is not only state-of-the-art but is simply named.

Snoop is one such program.  It snoops.  More than anything else out there, it lets you drill-down into the visual tree in a WPF application.

I could go on and on about it, but seriously.  If you’re doing any development in WPF, any serious development, you need this application.  Even if you’re just trying to understand WPF more, Snoop will expose WPF’s way of doing things more than anything you may ever find.  You just have to see it to understand what I mean.

Popularity: 16% [?]