Page 2 of 4   « previous page   next page »

Like Windows Forms before it, Avalon allows the creation of reusable GUI components called "Controls." This is the purpose of the Avalon Control Library Project.

Finally, there is a special kind of Avalon application which, although freestanding and not requiring hosting within a Web browser, can present a navigational look and feel that is most closely comparable to that of a Web browser. For these kinds of applications, the Avalon Navigation Application is the correct choice.

For my first work with Avalon I chose the standard Avalon Application project. It created a project with four files: MyApp.xaml, MyApp.xaml.cs, Window1.xaml, and Window1.xaml.cs.

In general, Avalon applications use a markup called XAML to define their user interfaces. Unlike previous approaches to defining Windows user interfaces, Avalon's use of XAML gives it a decidedly declarative model. This is to say that by using XAML, the controls that will appear on a given screen in a Windows GUI-based application are completely defined via markup - much as ASP.NET pages are currently constructed.

Also like ASP.NET pages, Avalon applications have the actions for their GUI elements defined in standard VB.NET or C# contained in separate files, known as "code behind" files. In the Figure 1, the files ending in .cs are the C-Sharp code behind files with which my Avalon application project starts me out.

Simply running the application presents a single, empty window with the caption "Demo" in its frame. In order to guarantee that I was fully up and running, I set myself a task of adding a single button to the user interface. When I click that button, I want a message to appear on the user interface telling me that it has been clicked.

The XAML needed to add a button to the User Interface turned out to be very simple, and is shown in below.

<Window x:Class="Demo.Window1"
   xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
   xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
   Text="Demo"
   >
   <Grid>
     <Button Name="MyButton">Does This Work?</Button>
   </Grid>
</Window>

The XAML's top-level node is the definition of a single Window container object. The first attribute on it - x:Class - indicates the name of the class that will provide the code-behind functionality for this window. The second and third attributes associate specific XAML XML namespaces with the document. The final attribute sets the text for the window. This is the text that appears in the title bar for the window, as described above.

Inside of the Window node, there is a Grid node. The Grid is a kind of panel that allows objects to be positioned within it using horizontal and vertical coordinates. The idea of different kinds of panels with different approaches to positioning content is extremely important in XAML. Ideally, a properly constructed XAML user interface should be able to resize itself automatically as the dimensions of the screen or device it is being used on change.

The Grid is a single button, which is the button to which our application will respond by setting its text differently. In this case, the XAML simply indicates that there should be a button, with the text "Does This Work?" as its caption.

The code shown in Listing 1 is what is contained in the Window1.xaml.cs file. At the top are the references to some of the new namespaces for Avalon that allow .NET to understand the XAML functionality used by this application.

After the references comes the line of code that tells .NET that all of this logic is to be contained within the Demo namespace. Within the namespace will be the class Window1. Notice that this class definition uses the keyword "partial," which is new to .NET 2.0. Partial classes allow a single logical class to be defined using multiple physical code files. In this case, the Window1 class is partially defined in this C# code-behind file, and partially defined in the XAML file.

Notice that the class and namespace in the code-behind file match what is in the x:Class attribute of the XAML - "Demo.Window1." This is how .NET knows which class in your application to associate with the XAML for your presentation layer.

Within the Window1 class there are two methods. The first is the basic constructor. As with .NET 1.1 Windows Forms applications, it begins with a call to "InitializeComponents" - an automatically generated method that should not be altered by the developer! After this call to Initialize-Components, we have added a line of code to associate a custom event handler with our button's Click event.

Our custom event handler is called MyClickHandler and it is the other method in the Window1 class. It simply sets the caption - in XAML, this is the Content - of the button to "CLICKED!" to let us know that our event has been received and handled.

It is worth taking a look at the contents of the two remaining files, as well - although they are far less interesting, in some ways.

<Application x:Class="Demo.MyApp"
   xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
   xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
   StartingUp="AppStartingUp"
   >
   <Application.Resources>

   </Application.Resources>
</Application>

This XAML is not for a specific GUI element but instead it's for the application as a whole. It has an x:Class attribute, just like the previous XAML, and the function here is the same - that of telling .NET which class to use to provide the code-behind functionality for this user interface. The namespaces also have the same functionality as in the other XAML file.

The one new feature in this XAML head node is the StartingUp attribute. This attribute tells .NET which method within the Demo.MyApp class to run when the application is first instantiated.

Page 2 of 4   « previous page   next page »