New Fun Blog – Scott Bilas

I’ve been learning WPF for some GUI tools I’m building, and it’s a whole new world. I feel like I’m back with .NET 1.0 in the late 90’s trying to inhale a bunch of new technology and patterns all at once.

It’s pretty exciting, even if I am joining this game very late.

As I work in the WPF world (and maybe WCF and other techs as I start messing around with them) I’ll be posting odds and ends here about research I do and dead-end paths I go down.

Not WinForms++

The first thing I learned is that WPF isn’t WinForms++ or even “WinForms in XML”. It lives in an entirely different universe. Though, for folks like me that have been stuck in that old world too long, WPF is initially going to feel like a simple upgrade of an old framework. There are a lot of similar-sounding classes and concepts in the new framework. These are merely false cognates.

I’ve been learning that it’s better for me to enter into new WPF concepts like a 101 student: by reading books and MSDN docs. I haven’t done that in a while. Normally I just bang on code and refine, using Google and StackOverflow to guide my way (and surfclarity to filter out spam sites like experts-exchange.com). I’m still doing that as I pick up WPF, but adding on top of it some serious reading.

Pro WPF in C# 2008 (available at Safari where I’m reading it) is my current favorite book for learning WPF concepts. Most books I come across are lame reference manuals disguised as tutorials, or sensationalized drooling over new tech with no real experience to back it up. The author does great things like quickly explaining a cool-sounding WPF concept, then telling you not to use it and why. Not all of WPF turned out to be a good idea, after all.

So, here are some of the key benefits I’ve noticed in the short time I’ve worked in WPF:

Layout and Composition

The problem of control layout (wrap, dock, table, stretch, fill, and so on) is solved. It’s nice of WPF to catch up with where HTML has been for a while, though in a much cleaner and more internally consistent way. Later versions of WinForms started to get somewhere with TableLayoutPanel and friends, but it’s still the same old underlying framework, where you run into limitations very quickly.

WPF lets you easily nest any control within nearly any other, and has a sensible system for guiding layout containers (attached properties rather than Control-derived least-common-denominator properties). It’s simple, for example, to put a pair of icons and a few checkboxes into each element of a ListView, and make it look good. Virtualization is automatic as well, given certain constraints. Trying to make any of that work in old WinForms requires a lot of custom code.

In fact, it was enough work in WinForms that I tended to avoid doing anything complicated. This led to UI’s that were easier to program but harder to use due to the need to break out elements or hide things behind the ubiquitous “more” or “advanced” buttons. Consider your average Tools|Options dialog and the custom toolwork required to make that work in a Form. This is why “field of checkboxes” settings dialogs proliferate in so many apps (see pic at right).

With WPF I’ve found it easy to not only wire up the initial draft of the UI, but also to go back and do a big reorg without any real trouble, and usually without significantly changing any code. I Just did it three times today, in fact!

A Special Note on XAML

Layout and composition are now typically done in XML, using Microsoft’s XAML. At first I was tentative on XAML compared to MXML due to the total lack of support for writing code inline in the attributes. Well, it turns out that viewmodels eliminate the need for much of that inline code (with the glaring exception of value converters – more on this in a future post). It’s also probably a good idea to keep code out of the XAML if you’re splitting the work with a designer. Having code in those attributes would not only get in the way, but would be brittle and hard to maintain.

The bottom line is that WinForms’ crazy InitializeComponent is gone. Bye bye merge problems and periodic, inexplicable total reorganization of that function by Visual Studio. Instead, we lay things out hierarchically in nice, simple, consistent, and nearly unreadable XML. Well, that’s what the visual designer is for.

Data Binding

I’ll admit I didn’t mess around with data binding much in the WinForms world. It just felt like too much work for what was a simple thing to do by hand. And WPF is vastly more complicated and capable than Forms, so it was intimidating at first.

But in WPF you really need to fully embrace data binding. I suppose it’s possible to do old UI-driven Visual Basic style state management in WPF, by putting everything in the codebehind, but you’re not going to get much support for this. All samples and tutorials you’ll find online use data binding. It really is how the entire system was designed to be used. Data binding is about a lot more than simply tying a textbox to a text string member. It’s about separation of concerns.

Thankfully, it’s not difficult to pick up. There’s some crazy complicated 20-levels-deep-stack logic that makes it all work under the hood, but the end result is that you just cover your eyes and type {Binding SomeName} on whatever field you want bound to your viewmodel and it magically works. “Except”, as they say, “when it doesn’t”. So far it’s been rare for me when something fails to bind, or binds to the wrong place, and I’m developing a bag of tricks to debug these issues. I’ll try to post some of these in the future.

Now, about that viewmodel thing. It’s also practically required to embrace the MVVM pattern in building up nontrivial WPF-based UI’s. This is the “separation” I mentioned previously. Now, this takes a lot of practice to figure out and to start applying correctly. It took me about two months to really grok WPF+MVVM. So be sure to budget time to learn and practice this. Read the article I just linked for a good introduction.

Styling

The problem of styling controls and windows is hugely improved. It simply isn’t possible to modify controls in WinForms without writing a totally custom solution. WPF takes a big step forward in enabling simple as well as complex styling of the standard controls. You can completely alter the look and visual behavior of any WPF control without a lot of work.

And then there’s Expression Blend, my new love interest. Blend is a tool for the design and styling of WPF UI’s, and permits dividing responsibilities between engineers writing code and designers building the look & feel. We have this exact split at work, in fact. Engineers will poke out a rough UI, and later on one of the game UI designers will take some time to upgrade elements to look cool and be consistent with the rest of the tool.

Blend has a goofy, nerdy interface, but it’s really growing on me as I use it every day. It’s far from intuitive, but is powerful in terms of designing controls and styles, previewing it all live, live live! in its awesome designer. It can even build your full Visual Studio solution from within itself. I do almost all of my design work within Blend, partially because VS2008’s designer is so awful as to be almost useless (haven’t used 2010’s enough yet to comment) but mostly because it’s more familiar to the Flash programmer within me. What can I say, I like arty tools.

Rendering

One of the reasons styling can be done so easily is that WPF doesn’t rely on the underlying OS window manager to draw checkboxes and so on. This removes all limitations on what you can change. If you use a tool like Snoop or Mole to take apart a UI control, you can see that every little graphical piece and state of it resolves down to primitive WPF objects that you can inspect.

For fun, I edited the template of the ResizeGrip control in Blend to see what makes it tick. This is the little triangular dotted thingy that sits in the lower right corner of most sizable windows. Blend showed me that it’s rendered using a simple brush that has a repeated pattern of gradient squares clipped to a little stair-step box. All vector so it scales nicely.

How does this new rendering model affect Remote Desktop, by the way? Custom-rendered windows typically perform poorly through RDP. Try running Chrome or iTunes through RDP, or nearly any app through VNC, on a low bandwidth VPN connection to see what I mean. In earlier versions of .NET, if a DWM existed on both sides, the WPF graphics primitives would get remoted directly. However, it seems that in .NET 3.5SP1 and newer, WPF is remoted completely as bitmaps.

Microsoft is saying that this should actually improve performance in many cases. Well, we can only expect a future of more complex, denser GUI construction (I mean complex in the UI tree sense, not in the end user’s perception of complexity). So the 100%-bitmap-remoting solution may be needed in the long term anyway. But I’m not sure I agree with the timing of this decision. Bitmap remoting so far performs an order of magnitude slower for me than graphic primitive remoting, at least in the everyday apps I use through RDP.

Bye Bye WinForms

It’s clear to me that anyone working in WinForms should ditch it as soon as possible in favor of WPF. Rewriting old tools is always a cost-benefit analysis, but for new tools, this is clearly the way to go. Especially if you’re in control of your user environment, such as within the enterprise, where you can force install the framework on every machine.

If you’re still hanging out in the WinForms world, or considering buying an expensive Forms-based UI package to pick up the pace on building UI’s, you really ought to take a hard look at WPF.

Don’t expect to be productive immediately, or even within a month. It will take a while to get used to it, learn the framework, and develop patterns to use in building UI. It’s time well spent. This is clearly the future.