A Visual Studio 2008 Solution with the complete code listing for this posting is attached.

Through the use of ControlTemplates we are able to customise the look and feel of all WPF controls. Here I will demonstrate using a ControlTemplate to make the ScrollBars of the ScrollViewer draw on top of the content it is scrolling rather than beside and below the content. Making the ScrollBars semi-transparent allows the content below to be seen through the ScrollBars.

Following on from my series on embedding DLR scripts in XAML, I present an implementation of John Conway's Game of Life in XAML/WPF using embedded Python scripts. The game is loaded completely from loose XAML. Even the initial game state is defined in dynamically loaded XAML files!

The game is hosted in the very dynamic application described in a previous post. Below is a screen shot of the hosted Game of Life applicaiton.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to this post.

To conclude this series of posts, I will build a simple application using many of the DLR Scripting goodies presented in this series. I will use Python as the scripting language, but you could use Ruby, JScript or any other language that has bindings to the DLR.

The idea here is to write a minimalist WPF application in C#, pushing as much logic as possible into the XAML and DLR Scripts, and as you will see, we end up with very little logic in the C# code!

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

As discussed in the previous article, GUIs are all about layout, style and wiring. WPF has the first two in spades; XAML is an excellent language for doing layout and styling of WPF GUI elements. However, sorely lacking in WFP is the ability to route commands and events in dynamically loaded XAML. This makes any attempt to build truly dynamic XAML based GUIs near on impossible as at some point you will have to handle an event, but it is hard enough to route an event to a static method let alone have a script execute in response to an event being fired!

Inspired by Josh Smith's work, I demonstrate how to use an attached property to establish a DLR script as an event handler for any WPF routed event.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

GUIs are all about layout, style and wiring. WPF has the first two in spades; XAML is an excellent language for doing layout and styling of WPF GUI elements. However, sorely lacking in WFP is the ability to route commands and events in dynamically loaded XAML. This makes any attempt to build truly dynamic XAML based GUIs near on impossible as at some point an event is going to need handling or a command issued.

Continuing the series on embedding DLR scripting in XAML, here I demonstrate how to implement a scripted WPF Command, making dynamically loaded XAML one step closer to being a first class citizen in the WPF world.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

The WPF Binging class is very powerful and its use should be encouraged. However, it can be cumbersome to do some very simple things with it, introducing a barrier to its use. One such barrier is defining a ValueConverter.

A ValueConcverter is a class that can convert the source property value of a binding before it is set on the target property. Often such conversions are simple expressions that do not warrant the creation of a new class - though this is what is done.

The first article in this series demonstrated how to host the DLR and presented some utility methods that make executing scripts simple. Here we build upon this to create a ValueConverter that evaluates a DLR expression that supports two way binding.

A Visual Studio 2008 Solution with the complete code listing for this posting is attached.

It is quite common to augment data with metadata. An example is the set of tags on this post. How would we represent such metadata in a XAML document?

XAML provides a method for augmenting our objects - the Attached Property. It would be very simple to have a "Metadata" Attached Property whose type is a collection of metadata objects. When this attached property is set, the metadata is stored in the appropriate place and cross referenced with the data object to which the metadata refers. Simple! Well, not really.

The Attached Property method is all well and good so long as the data object is a DependencyObject because Attached Properties can only be attached to DependencyObjects. It is possible, however, to use a MarkupExtension to do a lot of what an Attached Property does.

In this article I demonstrate how to use a custom MarkupExtension to register metadata for non-DependencyObject types.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

This article demonstrates how to embed DLR scripts in XAML using a custom MarkupExtension. The scripting language can be any language supported by the DLR, such as Python or Ruby.

The first article in this series demonstrated how to host the DLR and presented some utility methods that make executing scripts simple. Here we build upon this to create a simple MarkupExtension that evaluates a DLR expression.

A Visual Studio 2008 Solution with the complete code listing for this series is attached to the final part.

The XAML framework allows us to easily switch between the Declarative and Imperative programming models easily. Examples such as event handlers are obvious cases where this happens, while others, such as MarkupExtensions and ValueConverters for Bindings are not so clear - when you implement the ProvideValue method of a custom MarkupExtension, you are suddenly in the the imperative world of C# (or CLR language of your choice) where as the XAML document that declared the MarkupExtension is declarative in nature.

The ability to dynamically load XAML using the XamlParser class allows the programmer to switch in and out of the declarative and imperative worlds with ease, affording them great power and flexibility. Or so it would seem...

Dynamically loaded XAML does not integrate with the imperative world as well as it's compiled brethren. For example, you completely lose the ability to route events to handlers when loading XAML dynamically. This greatly hampers the usefulness of dynamically loaded XAML. The stance in the community is that you should simply compile your XAML if you want to handle events. In many instances this is just not an acceptable solution!

There are a number of interpreted (hence dynamic) imperative languages that bind to the CLR, such as Python and Ruby. The new Dynamic Language Runtime (DLR) will encourage the development off new dynamic languages as well as the binding of existing dynamic languages to .NET. In this series of 6 articles I will demonstrate how to embed any and all DLR languages in XAML.

A Visual Studio 2008 Solution with the complete code listing for this posting is attached.

The MarkupExtension in XAML opens up a world of opportunity to make XAML work the way you want it to. It reminds me somewhat of macros where we think of expanding the macro as substituting the macro for something else. If we consider that the MarkupExtension does nothing more than provide a value that is substituted for the MarkupExtension, it is very much like expanding a Macro.

Parameterised macros are extremely powerful as they do more than just save you typing, they can form a domain specific language. MarkupExtensions are stateful and you can set their state from XAML, leading to the idea that the substitution can be parameterised.

In this article I will demonstrate how to use a custom MarkupExtension as a macro or an object factory. The ideas will be applied to to a simple macro expansion case and the more pertinent case of creating a custom ValueConverter in a manner that is simpler than that provided by raw XAML.