Creating decent WPF applications is definitely hard for someone design-challenged as me. I've been trying to polish a small sample WPF client for a WCF service sample I've been playing with, and this is the best I've managed to come up with:

Ugly, isn't it?

Doesn't quite help the fact that, for some reason, the damn application just stopped using Visual Styles all of a suddent (don't know what's going on yet, but the controls are just not using the visual style anymore). Ohh well.

Like Jeff Lynch, I've been running the Virtual PC 2007 lately since my Vista RTM install. In general terms, it works just as well (or just as fair, more likely) as Virtual PC 2004. Like Jeff, I've always had the problem with the Centrino chipsets issues in Virtual PC (though in my case it's with the 950 set).

That said, I did try today adding the <enable_idle_threads> option to my virtual machine configuration file and it seems slightly better (at least it doesn't hog 100% of the CPU all the time). We'll see how it goes.

Meanwhile, I did ran yesterday into an ugly issue: Doing any WPF development on Virtual PC 2007, on my machine at least, is a big no-no. Sure, I knew from the start that WPF won't really perform well under a virtual machine, and that's fine; that's not the issue at all.

The problem I noticed was that running anything on the virtual machine that initializes WPF, even if it doesn't do any animation or 3D causes Virtual PC to take a long time to redraw the virtual machine screen. Seeing the response to, say, a click on a button, takes almost one second to render on screen. It's not that you can see the screen redrawing slowly either; the screen changes instantly, it just does so one second too late.

At first I thought something might be hogging my CPU, but I checked and both the host and guest CPUs are almost idled when this happens. In fact, I went so far as to connect through RDP to the guest OS and it is very responsive through remote desktop (well, as responsive as can be expected through RDP), so it's not like the whole machine is getting slowed down; it's just the VPC display rendering.

What's so bad about this? Is not that you can't run a full fleged WPF application; it's that you can't even develop one. Opening up a XAML file in Visual Studio with the .NET FX 3.0 Orcas extensions causes the issue as well, since the XAML editor initializes WPF for rendering. So, it's editing in Notepad2 for me, I guess. I bugged this, but somehow, I'm not expecting it to make much of a difference...

One of the things I've found very curious about the .NET Framework 3.0 libraries is that it has multiple definitions of what I presume are esentially the same classes. Have you noticed that there are two DependencyProperty classes, two DependencyObject classes, two PropertyMetadata classes and so forth? One for Windows Presentation Foundation and one for Windows Workflow Foundation.

I'm curious to know if there really is any significant difference between the two of them, and if not, why do we still have both? Mind you, we'll live with this forever, and at the very least it makes searching for documentation on them far more inconvenient (you end up looking at the wrong one at the most unexpected times!).

Robin Davies commented on my earlier post about custom controls in WPF, and he makes a pretty good point, I think, that perhaps WPF will help drive the presentation layer to have more designer involvement in the layout and presentation of rich clients, similar to how they now "own" the presentation layer (HTML) on Web Applications. That seems like something plausible, with the WPF theme, style and templating mechanisms filling the roles now handled by CSS in web application (it's not a perfect analogy, but it should suffice for the argument here).

When, and how this might take off, I don't know, honestly. I haven't taken a look at Expression yet, so I don't know how that will pan out, but from my original experience with HTML, it will probably take a while. Here at home it took a couple of years, at least, after doing Web Application work became mainstream, for graphics artists and designers to start doing HTML. Before that, they would just mock up the screens in Adobe Illustrator or a similar program and then just cut up the graphics for you, but it was our job as developers to create HTML that would render like their illustrator mock-up. So, it might probably be a while as well for graphics designers and artists to start coding XAML styles and templates, I guess

That said, I do not think that fully answers my questions regarding reusability, but it's a start.

While reading Chris Sell's and Ian Griffith's Programming Windows Presentation Foundation book, I ran across the following tidbit on chapter 9 on custom controls: "One of the main reasons for writing custom controls in older user interface technologies is to modify the appereance of a control, but as we've seen in earlier chapters, the content model and templates mean this is often unnecessary."

From what little I've experienced of WPF, the whole templating mechanism seems extremely powerful, particularly given the content model for UI Elements and the layout mechanism. Certainly, very impressive things can be achieved this way. That said, it does seem the whole templating mechanism can be just as easily abused (just like everything else in every other technology). So, where does the line get drawn between templating and creating new custom controls? Obviously, the second option takes more work (or so it seems to me, at this time), while the first can be more convenient.

Thing is, in my experience working with other smart-client technologies (WinForms, MFC, Win32), I found myself creating custom controls not just because it was the only possibility to affect behavior or custom draw a control (it isn't), but because it really helped make the code more modular and mantainable and make it self-contained (which helps reusability a lot, by the way). So, when I look at the templating mechanism in WPF, I find myself thinking that, while very cool and powerful, it could easily turn into a mantainance nightmare. In other words, I find myself asking "How is this different from, say, handling the Paint event for a child control in a Windows Forms and doing custom drawing there?" (from a code estructure point of view). At least from my little knowledge of WPF, I'd dread hundreds-of-lines XAML files with tens of templates and resources, just as much as I'd dread the corresponding windows forms code with hundreds of lines of embedded presentation, drawing and business logic.

I've been pondering about this for a while, and would love to hear the opinion of those of you that have been doing real-world WPF applications out there on the topic of reusability, templates and custom controls on WPF. Please, please convince me I'm wrong