Not too long ago I created a WPF panel that lays out its child elements in 3D space, called Panel3D. When playing around with it, I never could figure out a way to make the 3D models in the panel support transparency, such that you could see models lower in the z-order “through” models higher in the z-order. The models higher in the z-order (i.e. those appearing closer to the viewer) were always opaque, thus covering up models behind them.

Someone left a comment on that article, asking how to create semi-transparent items in Panel3D. I didn’t know the answer, but luckily someone else did. It turns out that I was adding the 3D models to the Viewport3D’s Children collection in the wrong order. Panel3D was putting the front-most model at the beginning of the Children collection (technically, the scene’s light source is the very first child). The index of a model in the Children collection matched its visible index, meaning that the element furthest away from the viewer was the last child in the Viewport3D. This was completely wrong!

It turns out that transparency of 3D models in a Viewport3D is a little more tricky than working with transparency of 2D elements living in a 2D world. For transparency to work correctly in a Viewport3D, you must add the models into the Children collection in the opposite order than which we see them (relative to the scene’s camera). If you want to learn more about this issue, go to this blog post, which explains the issue quite well. Unfortunately, the utility method offered in that post does not work in Panel3D.

I modified Panel3D so that it arranges the models in the correct order. The updated source code is not yet available, since I want to give it some time to marinate in my head before I revise the CodeProject article. I did, however, update the WPF Disciples Blog Viewer 3D (with audio) application so that it takes advantage of this new feature.

Download the app here: WPF Disciples Blog Viewer 3D (with audio!)

NOTE: Be sure to change the file extension from .DOC to .ZIP and then decompress it.

Here is a “before” picture, of what the app used to look like (click to view full size image):

Here is the “after” picture, showing how the transparency looks:

I also added two new dependency properties to Panel3D.

AllowTransparency must be set to true if you want the models to be “truly” transparent. If you leave it to false, the old behavior is honored, where the items become more “dim” when their opacity is lowered. The new WPF Disciples Blog Viewer 3D app, seen above, sets this to true, which is why you can see through the items.

AutoAdjustOpacity can be set to false if you do not want Panel3D to automatically set the opacity of each element displayed in the scene. The new WPF Disciples Blog Viewer 3D app, seen above, sets this to false, which is why the items do not seem to fade away as they move into the distance.

I will release the new source code and update the CodeProject article soon…I promise!

The Podder Skinning Competition is really starting to heat up now!  IdentityMine is now giving away their awesome blendables product as a prize to the winners.  The list of prizes has grown quite a bit since the competition first began, and this latest addition definitely cranks it up a notch.  Thanks a lot, IdentityMine!

I have already received a few e-mails and comments from people who are creating a Podder skin for the competition.  I can’t wait to see what they come up with.  Also, Karl told me that he is locked onto winning the steak dinner at Smith & Wollensky prize like a heat-seeking missile. 

Microsoft has announced the updates to Cider (the WPF designer in Visual Studio 2008 ) that will be part of SP1. Some of these improvements sound great! You can check out the entire announcement, but I’ve pasted the really interesting part below:

Features and functionalities that are new, changed, or improved

New features and new functionalities

Improved features and improved functionalities

I just published yet another article about WPF this weekend on CodeProject.  This one is about my new CommandGroup class, which allows you to create a “composite command.”  The article explains the problem that this class solves, but also explains that the solution has uses outside of just that one problem.  If you are interested in checking it out, here is the link:

http://www.codeproject.com/KB/WPF/commandgroup.aspx

I just published an article on CodeProject called ‘Creating the Same Program in Windows Forms and WPF‘. I think it provides some interesting information on the similarities and differences of WinForms and WPF, by showing how to implement the same simple application using both platforms. It is not a means of parading WPF and shunning WinForms. I tried to be as objective and down-to-earth as possible when discussing the relative merits of the two platforms.

My Podder Skinning Competition is officially one notch cooler now. Microsoft has offered to give each of the winners an 8 GB green Zune! That was a nice surprise!!

By the way, the most sought-after prize seems to be the steak dinner at Smith & Wollensky. Three people have already sent me e-mails saying that they are going to submit a skin into the competition just so that they can have me buy them a steak dinner. LOL! If you’ve ever been to Smith and Wollensky, I’m sure you understand…

I am excited to announce that I am hosting a new WPF competition!! This contest allows you to create and submit your own skin for Podder, the WPF podcast player application. Since Podder was built to support “structural skinning” it can use any UI that you dream up to display its data and behavior. This contest will allow participants to focus on using WPF to create an awesome user experience, without needing to worry about writing the underlying application functionality.

The Podder Skinning Competition, along with all the rules, prizes, and dates, is fully explained on this page of my blog. I also put together a step-by-step walkthrough of getting started with creating your own Podder skin, which you can check out here.

I look forward to seeing the creative Podder skins that people submit. This is a very exciting time to be a WPF developer or designer!

In my previous post, I showed a simple way to create animations in WPF using a sequence of images. That demo app used a LINQ query to get a sequence of BitmapImage objects based on the PNG files in a certain folder. Joe Rattz, the LINQ guru, dropped a comment on that post and also included his e-mail address. Big mistake!!

I sent him an e-mail, asking if the BitmapImage objects in that LINQ query are created every time a new enumerator is created and iterated over. When I send an expert an e-mail I never expect to hear back. I certainly don’t reply to all of the questions that people send me! There are only 24 hours in a day.

Luckily, Joe replied. Thanks Joe! It turns out that the answer is yes, the LINQ query is creating new BitmapImage objects for each new enumerator, as the enumerator is iterated. This is not a good thing. Since my demo app repeats the animation indefinitely, a potentially huge number of unnecessary BitmapImage objects were being created by the LINQ query.

The reason for all this is the fact that my LINQ query was only using deferred query operators. LINQ has deferred and non-deferred operators, as Joe’s book explains. If you use all deferred operators, the query’s results are not cached. Every time you iterate the resultset the query creates new objects for you. In some cases that is what you want. In my case, it is undesirable.

Working around this turned out to be easy, especially since Joe e-mailed me the answer.

I needed to apply a non-deferred operator to the query. This would cause the results of the query to be cached, so that all enumerators created against the query iterate the same set of objects. Here is the new code-behind for the demo app:

Notice how the entire LINQ query is wrapped in parenthesis and then a call to the ToList extension method is placed at the end. ToList is a non-deferred query operator, which is the magic that fixes the issue.

If you want the source code for this app, download it here. Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

As I tried in vain to fall asleep at a reasonable hour tonight, it dawned on me that something is missing from the standard WPF literature. Most of the animation examples show off the awesome built-in support for animations, which means changing a property’s value over time. What I felt was missing is an example of how to create an animation by showing a sequence of images in rapid succession.  Ya know, like Mickey Mouse.  So I got out of bed and made one!

I opened SnagIt, created 37 separate images, saved each one with a name like “001.png”, and then dropped them all into a new project in Visual Studio. All of the image files are copied to the project’s output directory, instead of saving them as resources in the assembly. After assigning the Window’s Content an Image element in XAML, I wrote the following code:

I just love using LINQ!  It makes data processing so much easier.  If you haven’t already done so, I highly recommend you read Joseph Rattz’s “Pro LINQ - Language Integrated Query in C# 2008“.

When I run the app, it looks like this:

If you want the source code, you can download it here. Be sure to change the file extension from .DOC to .ZIP and then decompress the file.

I have been heavily involved with WPF for years now. When I first started out with “Avalon” it was hardly a blip on the .NET radar. After just a couple of years the crickets have been replaced by a rock concert, and the intensity just keeps growing. For a WPF geek, such as me, this is great news!

My numerous encounters with people using WPF have lead to me to conclude that the platform is finally gaining traction in the .NET universe. WPF has been picking up momentum for a while in the financial services world, in particular. I have also met quite a few people using WPF in the state/local government sector, the retail sector, entertainment sector, and quite a few others.

But, wait a minute…why are people moving to WPF? Visual Studio 2008 offers rather weak design-time support for WPF. The lack of drag-and-drop magic in VS2008 essentially kills any hope of the rapid application development (RAD) that so many software shops hold near and dear. Why are people leaving RAD for MAD (manual application development)? In this blog post, we will discuss why WinForms and ASP.NET developers have decided to move on to WPF. Note, everything in this post is based on discussions I have had with people, but is certainly not the “definitive” explanation by any means.

The most obvious reason that people are now moving to WPF is that Visual Studio 2008 natively supports WPF development without requiring any extensions to be installed (i.e. the Orcas extensions for VS2005). Even though the WPF design-time experience still leaves much to be desired, the fact that it is part of VS2008 is important for many software shops. Most companies simply will not base their software development on pre-release bits; and I do not blame them.

In the previous paragraph, I mentioned that Cider (the WPF designer in Visual Studio) leaves much to be desired. Compared to the high-productivity RAD tooling support to which Windows Forms and ASP.NET developers are accustomed, it might seem surprising that anyone would drift away into the not-so-RAD world of WPF. Let’s take a closer look at exactly what this means.

Moving from ASP.NET to WPF is not too radical of a shift (so I’ve heard), in terms of tooling. Both platforms involve a markup file with an associated code-behind file. In both ASP.NET and WPF, the developer expects to go into the markup file and tweak the tags by hand. The design surface can only get you so far. From a tooling perspective, the shift from ASP.NET to WPF is not as radical of a change as for WinForms developers.

For those of us who approach WPF with a strong background in Windows Forms, however, you are pretty much required to remove your brain from your skull, rotate it 180 degrees, and put it back in.

This stems from the fact that WinForms developers are trained to never look at the designer-generated muck that is written for the Forms that they whip together in VS. The idea of working with markup that represents a UI is foreign to most WinFormers. Trying to move from a world where the serialization format used by Visual Studio to represent a UI is irrelevant, into a world where you are hand-coding XAML to get a UI together represents a significant mental shift.

This brings us back to the original question. Why are people moving to WPF at an increasing rate? I have heard several recurring themes when I ask people this question. Below I summarize each theme, and try to explain the rationale behind them.

Many people who moved from WinForms to WPF have told me that they are concerned about Microsoft gradually phasing out WinForms and concentrating their new developments and customer support into WPF. Many people feel that sticking with WinForms is just asking to be left in the dust. That is a very forward thinking idea, though I obviously have no idea how long it will be before WinForms is retired.

Another common theme I have noticed is that people are leaving WinForms for WPF because they want to incorporate advanced data visualizations in their programs. There seems to be quite a lot of interest in the possibilities of charts and graphs that a vector-based rendering system, which supports 3D, has to offer. Creating animated 3D data visualizations in WinForms is not exactly something that the average developer can do, but in WPF the barrier to entry is significantly lower. In my mind, that’s a very good thing (unless you happen to be making excellent money by creating advanced 3D data visualizations via GDI+).

The other common thread I’ve noticed is that people move from WinForms to WPF because they find certain aspects of the platform appealing. For example, many folks I meet tell me that the WPF data binding system alone was compelling enough for them to make the switch. I completely understand that!! From a developer’s perspective, things like triggers, routed events, rich data binding, and commands are extremely useful and addictive.

The last thing I have heard people say, but not quite as often, is that they want to have an easier way to involve a Visual Designer in their project. People who say that are typically working on a product, as opposed to an internal application for a company. For them, the idea that their aesthetically-challenged developers will not be responsible for designing the user experience is a powerful selling point for WPF adoption. Once again, I completely understand that!

The reasons why ASP.NET folks are moving to WPF overlap with the reasons listed above, for WinFormers. In addition, I have heard that some Web developers are just plain sick and tired of dealing with browser-incompatible HTML and CSS. I have met Web devs who originally got into Web programming because it made the deployment of their applications much simpler. They soon discovered that they traded the simplicity of development for simplicity of deployment. Pick your evil…

The other major reason that I hear of ASP.NET developers getting into WPF is so that they can get a jumpstart on Silverlight. Since Silverlight is planned to be a subset of WPF, many people find value in learning WPF now, so that they can apply that knowledge to Silverlight once it is officially released. I think that is a very wise plan.

What about you? Why have you started using WPF, or not? What are the key factors in your rationale for adopting or avoiding WPF?