Browse DevX
Sign up for e-mail newsletters from DevX


Learn to Write XAML Applications Today with Xamlon : Page 2

You don't have to wait for Longhorn to explore the benefits of Avalon, the runtime engine that underpins its presentation tier. Xamlon, the most mature third-party implementation of Avalon, lets you build XAML-based applications right now.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

XAML Document Structure
The code below shows a typical XAML document. Running it produces a display like Figure 3.

Figure 3. A Xaml document hosted by the Xaml viewer. The document doesn't fill the view because it hasn't specified window constraints.

<?xml version="1.0"?> <Canvas xmlns="http://schemas.microsoft.com/2003/xaml" xmlns:def="Definition" Width="600" Height="400" Background="AliceBlue"> <Canvas.Resources> <LinearGradientBrush def:Name="ShineGradient" StartPoint="0,0" EndPoint="1,1"> <LinearGradientBrush.GradientStops> <GradientStopCollection> <GradientStop Color="#2989CC" Offset="0" /> <GradientStop Color="#FFFFFF" Offset="0.5" /> <GradientStop Color="#906A00" Offset="0.52" /> <GradientStop Color="#D99F00" Offset="0.64" /> <GradientStop Color="#FFFFFF" Offset="1" /> </GradientStopCollection> </LinearGradientBrush.GradientStops> </LinearGradientBrush> </Canvas.Resources> <Rectangle RectangleLeft="10" RectangleTop="10" RectangleWidth="560" RectangleHeight="350" Fill="{ShineGradient}" /> </Canvas>

The document declares a Canvas object with a specified width and height. The canvas is the drawing surface on which the runtime engine lays out the various graphics primitives. In this case, there's only one primitive—a Rectangle object with a five step gradient fill, which I've largely adapted from one of the sample projects. You'll also see various namespace declarations in the preceding code. The schema declaration isn't strictly necessary, but will probably become so later when XAML parsers validate documents against formal XSD schemas.

For now, the "Definition" namespace is far more important (referred to here via the "def" prefix) because it plays the role of binding the declaration of a LinearGradientBrush to the Fill attribute of a Rectangle. XAML makes this possible through something variously referred to as either complex properties or composite properties. You can identify a complex property by its "X.Y" element declaration, meaning both that Y is used to alias an XML fragment declared in-place, and that Y is a property of X. In one sense, this is a practical workaround for the fact that XML node structures can't be directly assigned to XML attributes; but at a conceptual level it's also the realization of one of XAML's fundamental design tenets—that the object model and markup mutually describe one another (a precept already followed successfully by other XML APIs such as MSBuild and ASP.NET). In this instance, Canvas.Resources and LinearGradientBrush.GradientStops are both examples of complex properties. When the Rectangle references {ShineGradient}, the runtime engine attempts to resolve the reference within the current scope. Because Rectangle's parent is Canvas, it searches Canvas's complex properties (Canvas.Resources) for an appropriate declaration. Having identified the LinearGradientBrush declared there, it then instantiates this brush and passes back a reference to it. You'll come across many other complex properties as you work with XAML, and a detailed discussion of these is beyond the scope of this article. For now, it's sufficient to recognize their format, X-dot-Y, and to understand that they underpin both XAML's object representation and its object serialization philosophy.

Now look at Figure 3 again. The whitespace at the bottom right exists because the XAML document declares a Canvas object, but doesn't specify a Window in which to host it, so the Xamlon engine creates a default window whose dimensions are constant—and those dimensions have nothing to do with the size of your Canvas. If you resize the window it clips the gradient fill naively because there's no way to tell the renderer to do anything different. Let's add some events to rectify this, and find out how "class behind" code really works in the process.

Working with "Class-behind" Code
Xamlon terminology often uses the expression "class-behind" to refer to the fact that XAML documents can interoperate with code written in managed languages (e.g. C# or VB.NET). Specifically, class-behind files can access the XAML document object model to add, remove, or otherwise manipulate the elements within it. More importantly, XAML documents require a class-behind if they are to respond to user or framework events (Load, Resize, Click, etc.).

Figure 4. XAML Event-mapping: You can map events between a XAML document and a "class-behind" file associated with it. This figure shows the message box that pops up when you click the form.
The following example modifies the existing XAML file and adds a Click event handler. Doing this requires a number of changes.

First you'll need to create a C# class library project that exposes a standard Windows Forms OnClick handler with the usual signature.

public void OnClick(object sender, EventArgs e) { MessageBox.Show("Hello", "Message"); }

Next, you must restructure the XAML document. Because the Canvas object can't respond directly to events, the restructured version nests it within a Window object, wires the Click event to the name of the event handler, and adds a processing instruction to identify the namespace, class name, and physical location of the assembly containing the event handler. If you compile Example1, launch Example1.xaml, and then click on the window, you'll see a MessageBox as in Figure 4.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date