Jean-Michel Hervé, aka TuO, has left us yesterday. I've worked with him a few times during my demomaking years when I was an active member of Orion, and I had a lot of respect for the guy.

He was a particularly gifted coder, and will be remembered for many things like the excellent VIP2 invitation demo released in June 2000 when he was a member of the PoPsY TeAm. Lately, he was working in lyon as a developer at Eden Games.

Rest in peace, my friend.

Well, yet an other post on WPF and some DataBinding. But this time, this is about DataBinding to application settings that are automatically generated by visual studio. These settings come in handy when you want to save your application settings per user, or have some application wide settings. In my case, I wanted to have my application to remember its size and position, as well as the window state.

WinForms were providing an UI to do this, and I wanted to have all that functionality back. It is not all that "visual" as WinForms can do it, but it works rather well. I guess that Orcas will provide a way to do this visually.

All I had to do to use these settings from XAML was to create a resource to be usable for DataBinding, from a separate file :

WindowsApplication2 is the default namespace for the application, and since the Settings class is automatically generated, the default namespace is used. This resource will be used application wide and is referenced like this :

This is handy because resources are separated in multiple files. I also add here references to value converters, when I have to use them everywhere in the application. Value converters, yet an other interesting subject. Maybe in an other post :)

Now, about binding the data. We want to bind the Width, Height and WindowState of the default Window to some settings in the ApplicationSettings.

Here's what to do :

We create three bindings, each for an attribute, and set the source to the "settings" resource. The interesting part here is that the even thought the property we use is static, Settings.Default here, the Binding engine does seem to support it.

Setting the binding path to Default.MainWidth binds to the appropriate property. The last parameter instructs the binding to set the value of the property when the binding destination value changes, which can be the actual window height, for instance. The type of the property does not need to match the destination exact type, and since the type of the WindowState property is not known by VS2005 settings designer by default, setting the type to string seems to be enough.

Simple and easy. Now my application remembers where it was !

The sample here is a bit more complex, since it includes code to actually save the settings. But this is nothing really complex.

Man ! I like WPF... !

DataBinding is one of the technologies I like the most. 

Winforms did a fine job introducing the concept, but it was pretty easy to be stuck when trying to perform complex databinding. .NET 2.0 brought the concept of BindingSource, which eased the management of multiple "Current items" on a single form. You might have encountered this when creating multiple master/detail views on the same form. That was the case when you wanted to walk through a set of tables through their relations, say down to three levels.

WPF has a far more advanced DataBinding engine and introduces the concept of DataContext. There's the notion of a hierarchy of DataContexts and a databound control uses the nearest DataContext available.

An example is better than a thousand words. Here's a data source :

Now, let's bind this data to a list box, contained in a GroupBox to be a bit more readable :

This performs a binding to the attribute "name" of the level1 node list. The IsSynchronizedWithCurrentItem tells the listbox to set the CurrentItem of the current DataContext, which can be used to fill the next ListBox for the level.

Now, to add a new DataContext level, let's add a new GroupBox, and a stack panel to have a nice layout :

Now, there is a new DataContext for any children of the second group box, and is having the CurrentItem of the upper DataContext as a root. This is fairly easy to do, so let's do this for the final level.

Also there is a fine feature that came up when using this DataContext and CurrentItem : The CurrentItem "chain" for a specific path is -- when the data source does not change -- kept if you change the selection, and come back to that particular path. Pretty interesting.

Here is a working xaml sample of this post.

Did I say that a really like WPF already ? :)

Since this little website upgrade to add the blog, posts have been indexed by google with an ugly internal uniqueidentifier of mine.

Incidentally, that does not index well in google. Since the url to a post does not explain what the destination is about, I decided to add an url rewriting HttpHandler, to have the url containing the title of each post or category.

The part about writing the url rewriter has been covered over and over, oh and over, so I won't talk about it here.

Actually, I'm using CrystalTech web hosting -- like my brother Matthieu -- which works really fine, and does a fine job providing ASP.NET 2.0 services.

Their service is providing a tweaked Medium trust level to users, so hosted application have be configured that way. By tweaked, I mean that they re-enabled Reflection, Web, ODBC and OLEDB permissions from the Medium trust profile.

Anyway, you have to deal with Partially Trusted Callers. My application uses a class library in a separate assemnly, which needs to have the AllowPartiallyTrustedCallers attribute set, because of the Medium trust. That avoids this :

[SecurityException: That assembly does not allow partially trusted callers.]

So, if you choose CrystalTech web hosting, remember to try your website under the Medium trust profile to avoid suprises, with this :

<system.web>
   <trust level="Medium"/>
</system.web>

Also, on the side of differences between VS2005 web server and IIS 6.0 behavior : The default handler for any url in VS2005 is ASP.NET and in IIS 6.0 it is the file system. Since my urls are now generated, they definitely don't exist on the file system. I just had to add an ".aspx" at the end of my virtual url to get IIS 6.0 handing it to ASP.NET runtime.

Now I have my nice URLs :)

My younger brother has updated his website, with his new demoreel 2007.

Go check it out here http://www.sebastien-laban.com !

If you've tried installing Bluetooth Remote Control on your device, and you are having trouble, such as getting this message :

The file RemoteControl.ARMV4.CAB is not a valid Windows CE Setup file

You must be working on some Windows Moblile 2003 device. I did not have the time to fix this but if you are interested in getting it to work, you can proceed as follows, if you're familiar with a CE cab file structure :

• Expand the files on the PC using WinRar for instance,
• Rename 0SmartBT.001 to smarbt.exe
• Rename BTHelper.002 to bthelper.dll
• Just put those two files on the PPC wherever you want.

You won't have a nice icon on your programs list, but at least it should help you run it.

Enjoy !