Using the Visual Designer
|Figure 5. Xamlon Visual Designer: The Visual Designer makes it possible to visualize XAML documents within Visual Studio itself. You can switch between "Design" (code) and "Xaml" (visualization) mode.|
Wiring events is much easier inside the Visual Designer. In fact all you have to do to map most common events is to select the event from the "Properties" window while visualizing a XAML document with the focus set to the control whose events you are interested in. The Designer will stub out the method for you, just like a Windows Forms application. However, having hand-wired the events already, you now have some insight into how the Designer works. For example, if you take the original XAML file shown in this article, and drag-and-drop it into Visual Studio, you'll see something very different. Figure 5
shows how the file appears graphically, and Listing 1
shows the changes the Visual Designer has made to it.
In Listing 1
, the Visual Designer has mapped two namespaces, "wf" and "wfi" (for Windows.Forms and Windows.Forms.Integration respectively). It has also wrapped the Canvas node within an ElementHost node, wrapped this in turn within a Form.Controls node, and finally, added a Form wrapper around the whole thing. One effect of these changes is that they let the Visual Designer differentiate between "standard" Windows Forms UI elements and XAML-specific UI elements by mapping them to different namespaces. The Visual Designer also wraps XAML content within an ElementHost, which means you can embed XAML in a standard Windows Form, much like a Panel object. So if you think XAML's Button object looks remarkably similar to the existing Windows Forms Button, it's because the two are in fact identical!
Through IPageConnector you gain the ability to manipulate existing XAML elements as they get instantiated. Sometimes, though, you'll want to add data after your XAML window is up and running. Xamlon allows you to inject XAML data at runtime using the System.Windows.Seralization.Parser.LoadXml() method. You do still have to jump through a few hoops to get new XAML content integrated into a running WinForm though, so the sample Example 3 Project illustrates the techniques.
|Figure 6. Coloring by Numbers: The Toucan Tester shows an example of dynamically altering the underlying XAML content and displaying the results.|
First, the project hooks the Form's Load()
event to load the XAML document toucan.xaml
using a TextReader (XAML documents are fully XML compliant) and then caches it in an XmlDocument. When you click the form, the project uses an XPath query to change all the Fill
attributes within the document, which define the colors used for the various parts of the toucan. The code converts the altered document into a MemoryStream, loads this into Xamlon's parser to create a FrameworkElement object, locates the ElementHost control currently hosting the toucan, and finally, calls AddChild()
with this new FrameworkElement. Calling AddChild
on an ElementHost actually replaces any existing content with the new content you supply (perhaps AddOrReplaceChild
would be a more accurate signature). The result is that the toucan changes color randomly, every time you click the "Color Me" button (see Figure 6
). It's a stylized example, but it does show you how to combine XAML with XSLT or XPath, and how to get the runtime engine to display updates you make dynamically.
More often, though, you'll want to skip the loading step and work directly with the XAML primitives. The principle is basically the same. Take a look at the Xamlon "Floating Circles" sample application (Applications\Floating_Circles) which does just this, dynamically adding all its elements to a blank canvas at runtime.
The Future of Xamlon
Xamlon's founders haven't chosen the easiest path. On one hand, Xamlon may find market share because it offers Avalon's technology today, but will you want to use Xamlon when Avalon is finally released? A few months ago, many would have considered Xamlon because it offers back-level support for all the Windows variants that can run the .NET 1.1 runtime, but Microsoft recently pledged to implement WinFXthe technology that underpins Avalonon both Windows XP and Windows Server 2003. That still doesn't give Avalon quite as wide an O/S base as Xamlonbut does it make sense to target Windows 98 in 2005?
Despite Microsoft's announcement, I feel that there is a niche and market for Xamlon among developers and architects who need to begin getting up to speed on Avalon now, gaining the experience to make strategic decisions that may not include Xamlon itself, but may well include Longhorn. Releasing public betas so that the developer community can get to grips with this new technology has done much to endear me to the Xamlon initiative. While Xamlon itself remains a bit ragged round the edges in some respects (I'm particularly thinking of its dearth of SDK documentation), it's generally useable and stable enough that you can develop practical proof-of-concept applications with it out-of-the-box (for example, it comes with both a Calculator and an implementation of Solitaire as sample projects). This, taken together with Paul Colton's pledge, as Xamlon's founder, to "track Avalon" through XAML's changing specification forces me to conclude that Xamlon completely justifies its $400.00 price, and gives forward-looking developers a definite advantage when the first formal Longhorn projects kick off.