When we were in Quebec city last week training a group of people on WPF, one of the trainees asked a question :

   How would I go and change the "presentation" of the scroll bar.

This questioned was asked during one of the labs and so we had time (10 minutes) to come up with a quick answer, here is the walkthrough that we presented:

1. Subclass the ScrollBar control by deriving a new class from it, don't forget to add this code in the static constructor so that styles gets hooked up correctly :
   

      18             DefaultStyleKeyProperty.OverrideMetadata(typeof(MyScrollBar),

      19                 new FrameworkPropertyMetadata(typeof(MyScrollBar)));

2. Load up Reflector and locate the the PresentationFramwork.Aero.dll assembly in the GAC. This assembly contains WPF resource dictionaries that WPF merges into the application scope when a WPF application starts. WPF loads the correct dll "theme" file according to the OS that is running.
3. Install the BamlViewer addin for Reflector because the DLL doesn't contain readable XAML. It is stored by the compiler in a binary format in order to optimize loading and storage of these massive XML files.
4. Locate the section in the converted XAML that pertains to the ScrollBar control, copy that into your own resource section, rename a few things to "MyScrollBar" and voilà, a custom scrollbar.

This is the 1000 feet view on how to do skinning, and will require a lot more work when creating a custom style that works correctly (handling commands, events, triggers...).

It was a mere introduction to demonstrate the simplicity of the model that WPF uses to "present" controls.

Last week, Erik gave a 2 day training in Quebec city on the topic of WPF. He was amazed to see just how much interest there currently is for this new technology, especially now that SilverLight 2 got released.

These are some of the questions that were asked, as well as pointers to the answers:

1 - What do you recommend, a XBAP application or a SiliverLight one ?

   This is a hard one because it involves so many upfront decisions. If you do not control the computers that will run the application, a SiliverLight application is the easiest to deploy. At the same time, SilverLight applications have severe constraints (partial trust, doesn't benefit from the full .net framework, stripped down WPF, limited network access...) but benefits from advances like DeepZoom (checkout the DeepEarth project). XBAP applications are normal .net applications that are hosted in the browser (Internet Explorer) and are usually partial trust (as the assemblies are downloaded at run-time from a webserver).

2 - Should we write new controls ?

   WPF comes with so many extension points (skins, themes, control templates, data templates...) that should all be evaluated before actually writing a new control. In a upcoming post, we will explain the "on the fly walkthough" we used to change how scroll bars were displayed for a "trendy application". Writing new controls is still a possibility, allthough we think you will find that there are better ways to extend WPF.

3 - Isn't SilverLight just for making cheesy animations on the web ?

   SilverLight 1.0 was only able to work with WPF (through XAML) and was mostly used to display media. SilverLight 2.0 comes with an implementation of the .net framework which allows you to develop a lot of the same kinds of applications you do with the .net framework; think of it in the same way as you would the Compact Framework. One major difference with the Compact Framework (the one that runs on a Windows Mobile phone) is that there is no binary compatibility for assemblies and so code has to be physically recompiled. Microsoft believes so much in the SilverLight plateform for business applications that they are porting prism and unity to it (see here and here).

nVentive will be presenting it's "Top 10 Umbrellas" talk at the Ottawa.NET Community on Thursday, November 5th. Come and hear us talk about Umbrella and how the ideas within can save you development time.

One of the nice things of the latest versions of .net, is the ObservableCollection<T>. This class implements the new INotifyCollectionChanged interface (similar to INotifyPropertyChanged that we all know). Here is a small code example:

Notice the usage of ReadOnlyObservableCollection<T>, which can be used when you don't want someone to alter the contents of a collection.

These are the problems we see with all this new goodness:

1. These types reside in the WindowsBase.DLL assembly with weird innapropriate namespaces.
2. ReadOnlyObservableCollection<T> and ObservableCollection<T> implement INotifyPropertyChanged explicitly, meaning you have to cast to INotifyPropertyChanged to be able to use notifications.

nVentive will be sponsoring the Montreal .NET community, it's our way of promoting this great group. They offer many meetings per month where great subjects are featured. It's one of our ways of offering coaching and guidance to the Montreal community.

For the second time this year, nVentive will be presenting at DevTeach, happening in our home town of Montreal from December 1st to the 5th. Come and catch us talk about agility in our "Done Done" conversation, or about hard core programming in our "Top 10 Umbrellas" talk.