Brownie Points: Learning WPF

Supporting Input Binding for the Delegating Command

Thu, 18 Oct 2007 12:00:05 GMT

So after some research, I discovered what it takes to support Input Binding (E.G. key gestures) for the Delegating Command: absolutely nothing. Although you can configure a Routed Command's Input Bindings using the Command Manager, you can also do it in XAML using UIElement.InputBindings like so:

<Window.InputBindings>
<KeyBinding Key="B" Modifiers="Control" Command="ApplicationCommands.Open" />
</Window.InputBindings>

Here's the really fun part. You can configure Input Bindings for any ICommand (like a Delegating Command exposed as a property on your View Model (or Acropolis Part)). In all honesty, I'm seeing less and less use for Routed Commands. I for one won't be using them going forward.

It's time for us to begin sailing the 4C's again. I've just dusted off Part Two of Code Climber Custom Controls and it's going to be a doozy just like it's predecessor. It just needs one more evening/morning writing cycle to complete.

So this is Vista

Thu, 13 Sep 2007 16:44:02 GMT

I've been running Vista at the office since Beta 2. And although I ran it on my old mule of a laptop at home, it didn't quite have enough to enable Aero...I actually wish I had a screen shot of the 1.0 graphics score it got. While graphics are still a liability on my laptop...(I probably won't be playing Halo 2 on it), it did manage to get a 3.0. Everything else was in the high 4's. Now that I have a personal machine that can do everything Vista is capable of, I've had a few wow moments. Like when I did the win+tab switching while a video was playing in IE...(a Silverlight video no less) and it was streaming seamlessly in the preview mode. Or when I hovered over the task bar and saw the same thing. The screen shot Doesn't do it justice...but if you've seen it in action, you know what I'm talking about.

Before Vista was released, there were a lot of questions about just what advantage the DWM (Desktop Window Manager) would bring over User and GDI. There were even comparisons between the DWM and the windowing system for MacOS (sorry I don't know the name, I'm not a Mac programmer). To be honest there is no comparison. The DWM uses a retained model for graphics. What this means is that a window is asked to render itself once and the DWM stores the visual until the application tells it that it's visual is invalid.

For the average application developer, this doesn't bring a big advantage. But anyone who has made a custom control (pre-WPF) can appreciate not having to write additional code that re-renders the rectangle that was covered by a dialog. Basically, telling Windows that you want to update what the user sees is a lot easier to do than having Windows tell you that you need to update.

The end user of course benefits from this as well. And not just in the eye candy department (but if you think it doesn't matter, it does). Because the DWM retains the raw graphics calls that your window made to render itself, it can put those in a place that makes sense, like the ram of the video card. Think about it. The operating system itself leverages the power of your GPU. This translates into less strain on the CPU, which makes the operating system (and hence your app) more responsive. For free.

Knowing more about the DWM should help one get a better understanding of just what WPF is. It is a .Net wrapper around the first Windows API that was designed with .Net as a consideration. (User and GDI were created well before .Net was conceived.) To learn more about the DWM, visit this old post by Greg Schechter. He might know a tiny bit more about it than I.

Attached Properties, Markup Extensions, and MultiBindings...Oh My!

Tue, 08 May 2007 06:25:05 GMT

So, I've touted the advantages of Attached Dependency Properties extensively in the forums. One of my favorite uses of Attached Properties is the fact that you can use them to attach additional functionality to an object -- named the Remora Pattern by Ben Constable. Technically, I think it's a bit of a misnomer because a Remora doesn't provide any benefit to its host...it doesn't harm it, but it definitely doesn't provide any benefit. So, after a quick search through wikipedia for mutually beneficial symbiosis, I found the Egyptian Plover, also known as the crocodile bird. The plover eats parasites off of the crocodile, providing it relief from pests. In exchange, the Plover gets a veritable smorgasbord and the safest home in the Nile. Although the name remora does a good job at getting the idea of "attaching" across, it doesn't do so well with the idea of enhancement, which is what the pattern does. However, once a pattern is named, for consistency sake, we should stick to that name. Is this technically a pattern? I can think of three instances where it could be useful, beyond the one named by Ben in his blog.

The first example I will provide is the infamous Multiselect question: how do I select all checkboxes similar to an email client allowing a user to select all of his spam for deletion with one check. Yes, I know I just linked to an example of using attached properties to perform this very task, but I use a slightly different approach that lets me demonstrate a few more neat WPF tricks.

First we're going to need a source object that tells us whether all the checkboxes should be checked or unchecked. Let's call it a MultiSelectionSource. Our source needs to be a DependencyObject and should expose whether or not it's selected as a boolean dependency property

    /// 
    /// Dummy object that acts as a source for s. 
    /// 
    public class MultiSelectionSource : DependencyObject 
    { 
        public Boolean IsSelected 
        { 
            get { return (Boolean)GetValue(IsSelectedProperty); } 
            set { SetValue(IsSelectedProperty, value); } 
        } 


        public static readonly DependencyProperty IsSelectedProperty = 
            DependencyProperty.Register( 
                "IsSelected", 
                typeof(Boolean), 
                typeof(MultiSelectionSource), 
                new PropertyMetadata(true));

Now we should be able to declare an instance of our MultiSelectionSource as a resource in our Window/UserControl/FrameworkElement and bind our checkboxes IsChecked property to IsSelected right? Not so fast! If we bind our CheckBoxes to IsSelected, then they are either all checked or all unchecked.

And let's not forget the importance of the Checkbox...it probably should be binding to a property on our object model (or preferably on our Controller, but that's another post). If they are bound to MultiSelectionSource, then they can't bind to something else. Something else can bind to them...but let's not get into that religious debate. Needless to say we need a way for the MultiSelectionSource to keep track of the Bindings for us. Let's declare a list of Bindings for that purpose.

        internal List<BindingBase> Bindings 
        { 
            get { return bindings; } 
            set { bindings = value; } 
        }private List<BindingBase> bindings = new List<BindingBase>();

Notice that I declared the collection as internal. I could as well have declared it private, no one can access it from XAML. That's not the point. The point is that we have a way to store a collection of Bindings so that the MultiSelectionSource can target the Checkboxes. So how are we going to get the bindings from the Checkboxes to the MultiSelectionSource. If you paid attention to my XML comments, you already saw it coming: with a MultiSelectionTarget.

    public class MultiSelectionTarget 
    { 
        private MultiSelectionSource source; 
        public MultiSelectionTarget(MultiSelectionSource source, String path) 
        { 
            this.source = source; 
            this.path = path; 
        } 

        public MultiSelectionSource Source 
        { 
            get { return source; } 
            set { source = value; } 
        } 
        private String path; 
        public String Path 
        { 
            get { return path; } 
            set { path = value; } 
        } 
    }

I didn't get around to commenting this guy, sue me. Actually, ~~the code is the documentation~~ it's really simple your MultiSelectionTarget has a MultiSelectionSource and a String representing its path. It almost looks like a Binding...except it's not. The Path here represents the path on the target object (such as IsChecked on a Checkbox). And the Source will actually be the Target of the generated Binding.

So our scenario so far goes thus:

In our XAML we declare a MultiSelectionSource in the Window/UserControl/Listbox.Resources.
The MultiSelectionSource holds a List that it uses to track bindings with MultiSelectionTargets
We declare MultiSelectionTargets on our checkboxes that point back to our MultiSelectionSource
The Bindings are generated and added to the MultiSelectionSource, allowing it to (un)check a group of checkboxes at once

Hope that helps you...oh wait...how do we do steps 3 and 4, you ask? This is where the ~~Plover~~ Remora Pattern comes into play. But it's past my bedtime, so that will have to wait for later.

Code Climber: Custom Controls (Pt. 1 - The Window)

Sun, 06 May 2007 01:49:36 GMT

So two post ago I gave a brief overview of my 4C series. Unfortunately, after promising to deliver this first entry in the series, I realized that I'm assuming knowledge of WPF development in general. But fear not my fellow coders! Because we are starting at the same place that every Windows programming tutorial before starts: with a simple hello. Indeed, you can consider this a crash course in WPF development itself for new comers, although I would recommend further training before you go full-bore into WPF development (for the patient ones among you, I will be writing a proper series on general WPF development later).

But before we get to the good stuff we've got to get our development environment ready. Here's what you need:

Windows XP SP2, Server 2003 SP1, or Vista
.Net Framework 3.0 RTM (pre-installed on Vista)
Windows Vista SDK (provides a quick local reference of the .Net 3.0 APIs and support for compiling .Net 3.0 apps)
(optional) Visual Studio 2005 Professional or better. (I'd highly recommend downloading the trial if you don't have a copy. Express won't support integrated WPF development)
(optional) Visual Studio Extensions for WPF and WCF November CTP (provides additional support for WPF development within the Visual Studio 2005 IDE and integrates the Windows Vista SDK into the MSDN Library if installed)
Of course for a really cutting edge experience, you can download the latest "Orcas" CTP which provides the most integrated .Net 3.0 developer experience available today.

Although, Visual Studio 2005 and the VS Extensions are marked as optional, it is out of this series' scope to provide instruction on building WPF applications from the command line. I would feel bad about this except there is a free three month trial available for those following along (just click the link). Anyway, I'm going to take a quick break while you get everything set up for what comes next.

All done? Great! One more quick note, for the first version of this tutorial, I will only be providing code samples in C# and XAML. If I get enough requests, I will take the time to convert it to VB.Net as well. So on to the good stuff.

The first step is simple: create a new project in Visual Studio. If this is your first time using the extensions for WPF, you will see a new set of options for .Net 3.0 projects

Select the Windows Application (WPF) template and fill out the rest of the dialog as shown (you can select whatever location suits you best). After you hit okay, the base template for a WPF application will be created. You should see the following in your solution explorer:

The default WPF Windows app includes references to the most common WPF libraries that an app might need. It also contains two XAML files and their "code-behinds". The first XAML file and its code-behind defines a custom subclass of System.Windows.Application. The Application class provides all of the global application-level plumbing (just like the Winforms Application before it).

In addition to the Application definition, the project template includes a definition for a sublcass of System.Windows.Window in a XAML file (Window1.xaml) and its corresponding code-behind.

As I mentioned before, XAML is an XML-based markup language that is used by .Net Framework 3.0 to declare and instantiate CLR objects. WPF uses XAML to define UI, while Windows Workflow uses XAML to define...well workflows (or so I am told, I haven't worked much with it as of now). In order to expose as much UI capability as possible with as much simplicity as possible, a new framework was needed that gives easy access to everything from basic graphic primitives (normally accessed by GDI/GDI+ calls) through media playback (normally requiring DirectX or WindowsMedia knowledge) and including the controls we all know and love from Windows Forms (well most of them that is).

For a developer who has not had prior exposure to a Markup/Code-behind model (similar to what ASP.Net uses), WPF applications that use XAML may be a bit disconcerting at first. But it may be easier to come to terms with it if one were to compare it to a partial class. The XAML defines certain parts of the class (the UI in most cases) and is eventually compiled behind the scenes, while the C# defines the logic that listens for events on the UI and responds accordingly (MVC at its finest).

Again this is very similar to the programming model for ASP.Net. The UI (web page) is defined declaratively using an XML-based language. While the logic resides in a code-behind that listens for events on the UI and responds accordingly. The similarities don't end there, but that's for another entry.

I guess at this point, there's only so much that can be conveyed without a code sample. So here it is the XAML and code-behind that define the App class for HelloWorld.

    1 <Application x:Class="WPFTutorial.HelloWorld.App" 
    2     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    3     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    4     StartupUri="Window1.xaml"> 
    5     <Application.Resources> 
    6  
    7     </< span>Application.Resources> 
    8 </< span>Application>

App.Xaml

    1 using System; 
    2 using System.Windows; 
    3 using System.Data; 
    4 using System.Xml; 
    5 using System.Configuration; 
    6  
    7 namespace WPFTutorial.HelloWorld 
    8 { 
    9     /// 
   10     /// Interaction logic for App.xaml 
   11     /// 
   12  
   13     public partial class App : System.Windows.Application 
   14     { 
   15  
   16     } 
   17 }

App.Xaml.cs

So what did we do here? Let's look line by line starting with App.Xaml. In line 1, we see the root element, Application. Each element within a XAML file tells the compiler to create an instance of the class that the element represents. The classes are matched to elements through special CLR namespace to XML Namespace mapping. This can be done either through a special assembly-level CLR Attribute (XmlnsDefinition), or directly within the XAML using the clr-namespace syntax. There is an entire article dedicated to namespace mapping in the Windows Vista SDK. But to get the jist of it, read on.

By convention, the default namespace of a WPF XAML file is set to http://schemas.microsoft.com/winfx/2006/xaml/presentation. (The name winfx is a carry-over from the beta days of .NET framework 3.0 when it was called winfx.) This is seen in line 2 of App.xaml. This XML namespace is mapped to the majority of the clr namespaces for WPF using the XmlnsDefinition attribute. Also by convention, the x prefix is set to http://schemas.microsoft.com/winfx/2006/xaml This namespace is mapped to clr namespaces that provide supplementary support to XAML itself (mostly markup extensions). For instance in line 1 we see the x:Class attribute being applied to the Application element. This attributes tells the XAML compiler that WPFTutorial.HelloWorld.App defines a class that extends Application and is what this Application element refers to. This is similar to the Codebehind attribute that you will find on an ASP.NET page or control.

The default Application isn't too exciting. However, if you look at line 4 of app.xaml, you will see the StartupUri attribute with a value of Window1.xaml. This attribute maps directly to the StartupUri property of Application. This property tells the application what will be displayed first (similar to passing a Form to Application.Run in the WinForms world).

There is a lot more that can be done with your application's Application. There are event handlers to hook into, properties to set, the whole nine yards. We're not going to go into depth on that here. The point of showing it here was to give you, dear reader, knowledge of its existence. Its up to you to determine how best to use the tool in your arsenal.

On to the fun stuff! Here is the code for Window1:

    1 <Window x:Class="WPFTutorial.HelloWorld.Window1" 
    2     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    3     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    4     Title="WPFTutorial.HelloWorld" Height="600" Width="800" 
    5     > 
    6     <Grid> 
    7  
    8     </< span>Grid> 
    9 </< span>Window>

Window1.xaml

    1 using System; 
    2 using System.Collections.Generic; 
    3 using System.Text; 
    4 using System.Windows; 
    5 using System.Windows.Controls; 
    6 using System.Windows.Data; 
    7 using System.Windows.Documents; 
    8 using System.Windows.Input; 
    9 using System.Windows.Media; 
   10 using System.Windows.Media.Imaging; 
   11 using System.Windows.Shapes; 
   12  
   13  
   14 namespace WPFTutorial.HelloWorld 
   15 { 
   16     /// 
   17     /// Interaction logic for Window1.xaml 
   18     /// 
   19  
   20     public partial class Window1 : System.Windows.Window 
   21     { 
   22  
   23         public Window1() 
   24         { 
   25             InitializeComponent(); 
   26         } 
   27  
   28     } 
   29 }

Window1.xaml.cs

Again, the code doesn't do much and if you ran this application, you'd get a blank window. The XAML for this window is quite simple, consisting of two elements the Window itself and its child, a Grid. A Window can only have one direct child. That child is usually a descendant of Panel. However it can be a Button, a TextBlock, or whatever you want it to be. For some developers, the Window is the only control they will customize by composition (I.E. adding other controls to the window).

Let's wrap this overview of the window in classic fashion. We'll add some text to our window to say hello. Open up Window1.xaml and within the Grid element add the following:

    7     <TextBlock 
    8       FontSize="50" 
    9       FontWeight="Bold" 
   10       VerticalAlignment="Center" 
   11       HorizontalAlignment="Center" 
   12       TextWrapping="Wrap"> 
   13       Hello World From WPF! 
   14     </< span>TextBlock>

We now have a window that greets us like so:

So that's it! You've made your first custom WPF control. This actually turned more into a WPF first steps tutorial, but it was also necessary to help give a solid foundation into what a control is in WPF and how it can be customized.

Up next! The UserControl.

Code Climber: Custom Controls (Pt. 0 - WPF Meet World)

Mon, 12 Feb 2007 07:23:36 GMT

So I was writing my first entry in the 4C series when it came to me: I don't think I've given a proper introduction to WPF. Well at least not since it was fully released. Although there are a million places one could go to get a quick overview. I figured it wouldn't hurt to make that a million and one. So without further ado, I give you my dear reader:

A No-Holds-Barred Marketing Free Overview of WPF

What is WPF? It is a simple question, but the evidence suggests that it is not such a simple answer. On the official WPF Community Site, Microsoft provides a WPF overview presentation in four varieties 1, 3, and 5 slide, and 1 hour. Here's the simple synopsis: the Windows Presentation Foundation is a framework that provides support for the presentation layer of a Windows application.

Yes I know what you're thinking: doesn't Windows Forms already provide a full day's supply of my application's UI needs? Well yes and no. There are many applications that can do just fine with what windows forms provides. But there are definitely more capabilities of Windows that can fall under the "presentation" umbrella other than forms, buttons, labels, and textboxes. In order to tap into those other capabilities, a developer needed familiarity with other APIs like DirectX and GDI+. This led to a lot of the rich visualization that Windows is capable of not being used by line of business app developers who, rather than taking the time to learn and utilize complex frameworks, felt their efforts would be better put to use in creating functionality rather than "prettying" up their UI. WPF takes the power normally wielded by DirectX and GDI specialists and makes it more accessible.

Okay, maybe that wasn't as marketing free as I anticipated. At least I didn't use "paradigm" or "ROI" or "TCO". Essentially WPF takes all of the disparate Windows APIs that could be used as part of an applications presentation and puts them in a single package. And that package just happens to be at the center of the new .Net Framework. Microsoft highlights the importance of WPF by starting its packages with System.Windows (whereas the Winforms packages begin with System.Windows.Forms).

In addition to the new framework, Microsoft has provided a new XML-based language (yes it's an eXtended Markup Language based Language) called XAML (eXtensible Application Markup Language). That's fine and dandy, but to top it off Microsoft created a compiler that can interpret XAML and create runtime objects from it. XAML can be used by itself or with a code-behind (partial class to be precise) that serves the same purpose as an ASP.Net code-behind: handling events generated by the XAML using imperative code.

So What Does This Mean for Me?

There are several significant points here:

WPF makes advanced presentation technologies easier to access.
XAML provides a method to declaratively layout a desktop interface (similar to HTML for web apps).
XAML layout can be separated from general application coding allowing designers to design the UI while developers code the logic.
Line of Business desktop apps can now take advantage of rich visualization without compromising functionality.
You get to take advantage of a new Paradigm in windows development that can increase your company's ROI and lower the TCO over the life of the application. (Sorry...had to let my inner marketer out for a second).

Now that I've given a VERY high-level overview, let's get to the good stuff. Up next...the Window.

As if you didn't already know...

Tue, 07 Nov 2006 21:48:38 GMT

.Net Framework 3.0 has RTM'd (and is available on subscriber downloads). FINALLY I can stop uninstalling/reinstalling the latest Beta/CTP/RC version. Maybe I'll re-image my workstation to make sure that it can breath.

Also of note is that Office 2007 has RTM'd as well. I JUST put the Beta 2 Tech Refresh on my machine (I'm loving the new logos), but since I'm doing a re-image anyway, why not drop the final version on there as well?

Now if I can get through the rest of this project, I might have some time to go back to tinkering with WPF!

WPF Navigation: The Basics

Mon, 24 Jul 2006 06:11:48 GMT

Remember how I compared WPF programming to ASP.Net development. Well the comparison goes separating UI design and logic development. Just like web applications, WPF applications can navigate from page to page. Also like a web application, navigation pages can occupy the entire window or a designated frame on that window.

What benefit does this bring?

If you think of a Dashboard application, the primary functionality is presenting data. The main window can be a series of links to the various reports that are of interest to the user. What's more, the dashboard can be embedded in a larger app that provides more functionality. The real beauty of it all is that the pages of the dashboard do not have to care about whether they are embedded or not. All they have to worry abut is showing their data. And just like a web application all it takes is a hyperlink to move from page to page.

But if you want to get beyond just showing data and actually want to collect data from your users, all but the simplest of tasks would create a messy web of dependency between your pages.

That is where structured navigation and PageFunctions come into play. But I'm getting ahead of myself. We'll learn about that in the next entry.

Documentation Almost There

Sat, 22 Jul 2006 09:09:25 GMT

When I first started learning WPF, the documentation was in its infancy. Thus, I did most of my learning by reading blogs, looking at samples, and tinkering. Well I decided to really sit down with the documentation provided with the June CTP and I must confess that it is quite impressive. The dreaded learning cliff of WPF programming (that the majority of early adopters had to scale) has been tamed. Want to learn about WPF, open up the docs and start reading.

With the upcoming books from Charles Petzold and company, there will be plenty of material to help the new comers get a handle on WPF development. Of course they will miss all the fun of blazing a new trail, but I guess it's not for everyone.

IErrorProvider in WPF

Sat, 22 Jul 2006 09:01:13 GMT

Not too long ago, Paul Stovell, a fellow WPF apprentice asked if there was a way to get a list of all bindings in a control on the WPF forums. After a little bit of diving into the documentation, I found the LogicalTreeHelper, a helper class that you can use to walk the logical tree of a control. (Combining that with reflection allowed him to get the bindings). Paul wanted to use this functionality for his implementation of IErrorProvider for WPF. Today I stumbled across the ValidationRule class that provides similar functionality to what IErrorProvider did. Bea Costa, WPF DataBinding guru extraordinaire, has a blog entry (look under the March 2006 archives) in which she shows its usage.

Growing Pains

Thu, 13 Jul 2006 18:34:16 GMT

So I finally upgraded my machine to the June CTP of .NetFX3 and found my code was broken.

Basically it was complaining that an ObservableCollection in my control was null during initialization. In Beta 2 it would just initialize my collection for me. Before this code would work

<tempNS:MyControl>

   <tempNS:MyControl.MyCollection>

        <tempNS:MyCollectionItem ..../>

        <tempNS:MyCollectionItem ..../>

        <tempNS:MyCollectionItem ..../>

   </tempNS:MyControl.MyCollection>

</tempNS:MyControl>

Now I have to explicitly declare the new collection like so:

<tempNS:MyControl>

   <tempNS:MyControl.Collection>

      <tempNS:MyCollection>

        <tempNS:MyCollectionItem ..../>

        <tempNS:MyCollectionItem ..../>

        <tempNS:MyCollectionItem ..../>

      </tempNS:MyCollection>

</tempNS:MyControl.MyCollection>

</tempNS:MyControl>

I was wondering why it happened and got my answer here . Basically, the framework used to initialize collections for you (if they weren't already). But that turned out to be problematic, so they removed the functionality from the framework.

I fixed my problem by initializing the collection within the Control's constructor. I guess that's a growing pain of working with the latest and greatest. I wouldn't have it any other way

Journey to the Past

Wed, 12 Jul 2006 17:14:59 GMT

In order to appreciate better what WPF brings to the table, I feel it's necessary for me to learn about its predecessor, GDI+. At the office, we have an amazing library of books related to .Net programming, software architecture, mathmatics, basically anything that will assist us in becoming better at what we do (cranking out software). One book I found in our collection was GDI+ Programming in C# and VB.Net. Although it's not the most recent book in the world (published in 2002), it is a pretty encompassing text on everything you can do with GDI+ and it even gives some introductory background on how it improves upon GDI (the precursor to GDI+). GDI+ is essentially a .Net wrapper around GDI that adds the power of object-oriented programming to a procedural API.

From the first example, the author (Nick Symmonds) shows how GDI+ simplifies the task of drawing a line from six steps in GDI to three in GDI+. It truly is as dramatic as going from creating a form based application using the Win32 API to developing in Winforms. WPF is a similar leap in terms of ease of development (once you get past its learning curve).

So my goal is to learn GDI+ and discover what it takes to transistion the skills required for GDI+ programming to WPF. My hope is that this process will make me a stronger WPF developer.

The other book that I will be referencing is Programming WPF by Chris Sells. I will be using that book to learn how to translate GDI+/Winforms code into WPF code. The next post will be my first side by side comparison of GDI+/Winforms development and WPF development.

Why WPF

Fri, 07 Jul 2006 15:04:06 GMT

WPF is an exciting new technology and I will be writing a lot about it in the upcoming days/weeks/months (you get the picture). Before we get into code samples and such. I want to go over why WPF is so exciting.

I'm sure you've been inundated about how Windows Vista is the most dramatic change in Windows PC computing since the release of Windows 95. Although, the PR people will quickly emphasize that Vista is much more than just a new pretty UI (they are right), it would be a mistake to overlook the fact that the graphics subsystems in Vista are major improvements over previous iterations. I won't go into details here, but if you'd like to know more, a good place to start is Greg Schechter's Blog. Suffice it to say that the possibilities it creates are exciting.

So let's answer the question on everyone's mind. What's so big about WPF?

XAML (rhymes with Camel)
Ummm...there is no 2. XAML is the big thing about WPF.
Actually, I lied there is a number two and several points after but they all point back to 1.
Okay that's wrong too there are other highlights in WPF that aren't directly tied to XAML but they are a bit more technical than I care to go into now. (Again, I'll point you to Greg Schechter for more technical discussions.)

XAML or eXtensible Application Markup Language, is basically the representation of UI in XML. XAML brings the power of declarative UI programming to Windows desktop applications. I say desktop applications because ASP.Net apps already have a similar feature called html.

One major feature of ASP.Net development is that logic is CLEARLY separated from presentation. Well it is possible to have scriptlets of logic within an ASP.Net page and to imperatively create HTML elements in a code-behind file; but for the most part ASP.Net supports a model of separation, leaving UI Design to designers and business logic to coders.

WPF gives desktop applications a similar development model with XAML. Of course, a developer is free to create his (or her) WPF application using all imperative code. He would also be free to create his web app using only ISAPI.

This is the big deal regarding WPF. For the first time, designers can create their mockups using a tool that is targeted toward designers (namely Expression Interactive Designer) and have it immediately useful for developers. The reverse is also true. Developers can create a basic UI for their application in Visual Studio and a designer can use the same files to enhance the UI in Expression. Gone are the days of designers creating mockups in a graphics tool and developers having to translate that look into a windows form. XAML creates a bridge between developers and designers that simply did not exist before. If you're not excited yet, you should check your pulse.

Using WPF Imperatively

Sat, 01 Jul 2006 13:31:19 GMT

I bumped into a relatively old posting on Rob Relyea's blog that talks about the differences between using XAML for your UI and using imperative code (C#, VB). The entry was in response to one in Charles Petzold's blog where he asks if this disparity was purposeful or accidental.

I would just have to ask Charles if he has looked at the code generated by the Winforms Designer lately?

Let's say I create a form with a DataGridView holding three columns. Here is the generated code for that very simple UI

private void InitializeComponent()
{
this.dataGridView1 = new System.Windows.Forms.DataGridView();
this.Column1 = new System.Windows.Forms.DataGridViewTextBoxColumn();
this.Column2 = new System.Windows.Forms.DataGridViewTextBoxColumn();
this.Column3 = new System.Windows.Forms.DataGridViewTextBoxColumn();
((System.ComponentModel.ISupportInitialize)(this.dataGridView1)).BeginInit();
this.SuspendLayout();
//
// dataGridView1
//
this.dataGridView1.AllowUserToAddRows = false;
this.dataGridView1.AllowUserToDeleteRows = false;
this.dataGridView1.ColumnHeadersHeightSizeMode = System.Windows.Forms.DataGridViewColumnHeadersHeightSizeMode.AutoSize;
this.dataGridView1.Columns.AddRange(new System.Windows.Forms.DataGridViewColumn[] {
this.Column1,
this.Column2,
this.Column3});
this.dataGridView1.Dock = System.Windows.Forms.DockStyle.Fill;
this.dataGridView1.Location = new System.Drawing.Point(0, 0);
this.dataGridView1.Name = "dataGridView1";
this.dataGridView1.ReadOnly = true;
this.dataGridView1.Size = new System.Drawing.Size(292, 266);
this.dataGridView1.TabIndex = 0;
//
// Column1
//
this.Column1.HeaderText = "Column1";
this.Column1.Name = "Column1";
this.Column1.ReadOnly = true;
//
// Column2
//
this.Column2.HeaderText = "Column2";
this.Column2.Name = "Column2";
this.Column2.ReadOnly = true;
//
// Column3
//
this.Column3.HeaderText = "Column3";
this.Column3.Name = "Column3";
this.Column3.ReadOnly = true;
//
// Form1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.ClientSize = new System.Drawing.Size(292, 266);
this.Controls.Add(this.dataGridView1);
this.Name = "Form1";
this.Text = "Form1";
((System.ComponentModel.ISupportInitialize)(this.dataGridView1)).EndInit();
this.ResumeLayout(false);
}

So you see imperative UI code was always verbose. It was just hidden from us by the designer. I guess a case to consider is allowing Cider to generate imperative code as well as XAML...but why?

Arms Race

Fri, 30 Jun 2006 04:49:08 GMT

One of the greatest features of WPF is that it makes Desktop Development accessible to Designers like never before. Although I'm sure you've seen it already, I'd like to point you to Lee Brimelow's theWPFBlog.com. Lee comes from a flash background and writes his blog from that perspective. He has a number of examples of how simple WPF makes desktop programming for designers.

Recently, he asked in the MSDN WPF forums if it was possible to create a glass effect on Windows XP. I answered that with the introduction of transparent windows in the June CTP, it would be easier than before. I planned to (and still plan to) create an example showing the effect, but before I even got home, Lee had his example up. It took four lines of code in WPF to do this (in Xaml it would have taken one element declaration but who's counting)

   this.WindowStyle = WindowStyle.None;
   this.AllowsTransparency = true;
   this.Title = "Badass Drive Explorer";
   this.Background = new SolidColorBrush(Color.FromArgb(0, 34, 34, 34));

This code comes from his Window.OnInitialized() function. I know I have an example of creating a translucent window using GDI/GDI+ around here somewhere; but suffice it to say that it's not as simple as this.

Now if only there were a technology that made us mere programmers better designers