This blog certainly is not intended to be a reposting platform for yours truly, but I can't not mention a new tool (source code included) that allows you to inspect the visual tree of any Avalon application and even let's you see events and databinding!

It should prove to be an incredible help while debugging/learning/profiling your WPF applications. Get snoop here, and never look back again

An article has just been published on code project by Josh Smith that should not escape your attention: Piping value converters in WPF.

Basically, he has written a simple class that will allow you to define a group of converters and use it during databinding like so:
    <local:ValueConverterGroup x:Key="statusForegroundGroup">
      <local:IntegerStringToProcessingStateConverter  />
      <local:ProcessingStateToColorConverter />
      <local:ColorToSolidColorBrushConverter />
    </local:ValueConverterGroup>

and then use it like so:

        <TextBlock
          Text="{Binding XPath=@Status,
                 Converter={StaticResource statusDisplayNameGroup}}"
          Foreground="{Binding XPath=@Status,
                       Converter={StaticResource statusForegroundGroup}}" />

This should prove very valuable indeed!

A small tip today on how to access elements that are embedded within a control template. In my case for an itemscontrol class.
Consider the following Xaml:

Just a little tip, showcasing the power of Xaml and the efficiency of good code/design separation.

When you are fetching data from a server, you could (and actually should) use the DataModel-View-ViewModel pattern, as described by Dan Crevier from the Microsoft Max team. It uses a viewmodel-class to bind your Xaml against. Dan then implements a 'state' property to indicate whether the model is finished fetching and is in a 'bindable' state.

If you are short on time, or have other reasons not to implement such a strategy, you are probably binding straight to objects that are still Null during the fetch-action.
In either case, it would be nice to let the user know that data is being fetched.

In my case, I had a lot of <TabItem>'s that are being filled with data, one-by-one, by setting the datacontext directly. While designing the user interface, I do not want to have to think about the possibility of binding against an invalid object (it being null). So I created a style, that I put in the application resources. The style replaces my content-template with a temporary template, whilst in invalid state. I was extremely satisfied with the solution, because it was so dead-easy, and it works like a charm.

Here is the code (don't mock my visually stunning border please ):

I was pleasantly surprised by the simplicity of the code. The DataContext is used in a trigger to set the content-template.

Microsoft apparently had reasons not shipping WPF with a datepicker control. In my opinion such a control is of great importance when you are building applications. How can I sell a platform to a client when I have to explain that they won't be able to visually enter a date? (Or have to hire me to build such a control for them )
Some time ago I started a forum thread about this issue and the ATC Avalon responded by taking up the challenge and started working on a control. Why that team was dismissed is beyond me, but Kevin Moore finished where they left off. He has posted an update to his bag-of-tricks for the July CTP (they also work on the June CTP), and has included the datepicker sample!

I've quickly checked it out and it's looking great! I wish I could use empty dates though, but that should be easy to hack in.
Thanks Kevin!

I love Dependency Properties. Especially attached properties. There is just something extremely cool about being able to think up some property and then setting that in a datatemplate. For instance, creating a custom panel with your own attached properties, and reading these properties during the measure and arrange bits of the layout.
But when you do a get on the property, you will find your left with an unset value!

The backing mechanism for such properties use the object you set them on as a key. When you only have a UIElement, you can not read the value using the UIElement, because you never bound the property to a UIElement, but to your own visual in the datatemplate.
So always remember to use the original object when you are getting your value.

In the case of the UIElement in an itemscontrol, you will find that it is actually a wrapper around your original visual. Get to it by using the infamous visual tree helper:

DependencyObject o = VisualTreeHelper.GetChild(uie, 0);

Then use 'o' in your getvalue!

The sdk team has published all the WPF beta 2 samples as a zip. They are right here, http://www.wcsdkteam.members.winisp.net/wpfsamples.zip. Leave comments about problematic downloads at the sdk blog.

POCO power is announced by Roger Johansson, a lead developer of the NPersist OR-Mapper.
He writes: 'NPersist entities now supports 2 way databinding and edit cancels straight out of the box while still being fully POCO.
So as far as I know, NPersist is the only .NET mapper capable of this while being POCO (at design time that is)'

The question I ask myself is, do you really want this? I admit I haven't used npersist for long, because I switched to nHibernate. But, having read Roger's blog for some time, I believe they are quite advanced in the proxy area, using IL.Emits all over the place for incredible speed (the only way to do it!). They certainly seem to have taken this path, giving as much luxury to the developer by doing all kinds of stuff dynamically. And yes, edit cancellation certainly seem like a nice feature to have out of the box. 2 way binding as well.

But then again, what if I want to switch to WPF? It supports the old way of propertynameChanged events, but I'd rather use the new Avalon flavor.
And I have built my own canceling, by using structs as the backing store of my properties. What if I want the 'loaded' state of my objects to also serialize, then I want my own solution where I can easily do that.

By doing too many things that are hard to follow for a developer, you will confuse them.
Most importantly, by doing too many things, you are locking developers into your technology.

I'm against that.

Then again, I'm also a bit jealous. I had to do all of that myself! I hope that their puzzle-framework uses a pluggable architecture, where you use a configuration file to 'plug in' capabilities to the proxy system, even allowing custom capabilities to be created. That would be awesome.

(If your into that kind of stuff, your best bet is the Castle framework. Check it out.)