C H A P T E R 2 7

■ ■ ■

Introducing Windows Presentation Foundation and XAML

When version 1.0 of the .NET platform was released, programmers who needed to build graphical desktop applications made use of two APIs named Windows Forms and GDI+, packaged up primarily in the System.Windows.Forms.dll and System.Drawing.dll assemblies. While Windows Forms/GDI+ are excellent APIs for building traditional desktop GUIs, Microsoft shipped an alternative GUI desktop API named Windows Presentation Foundation (WPF) beginning with the release of .NET 3.0. This initial WPF chapter begins by examining the motivation behind this new GUI framework, which will help you see the differences between the Windows Forms/GDI+ and WPF programming models. Next, we will examine the different types of WPF applications supported by the API, and come to know the role of the several important classes including Application, Window, ContentControl, Control, UIElement, and FrameworkElement. During this time, you will learn to intercept keyboard and mouse activities, define application wide data, and other common WPF tasks using nothing but VB 2010 code. This chapter will then introduce you to an XML-based grammar named Extensible Application Markup Language (XAML). Here, you will learn the syntax and semantics of XAML, including attached property syntax, the role of type converters, markup extensions, and understanding how to generate, load and parse XAML at runtime. As well, you will learn how to integrate XAML data into a VB 2010 WFP- code base (and the benefits of doing so). This chapter wraps up by the integrated WPF designers of Visual Studio 2010. Here, you will build your own custom XAML editor/parser, which illustrates how XAML can be manipulated at runtime to build dynamic user interfaces.

■ Note The remaining WPF chapters of this book will introduce you to Microsoft Expression Blend, which is a WPF-centric tool dedicated to the generation of XAML on your behalf.

The Motivation Behind WPF Over the years, Microsoft has created numerous graphical user interface toolkits (VB6, raw C/C++/Windows API development, MFC, etc.) to build desktop executables. Each of these APIs provided a code base to represent the basic aspects of a GUI application, including main windows, dialog boxes,

1165 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

controls, menu systems, and other basic necessities. With the initial release of the .NET platform, the Windows Forms API quickly became the preferred model for UI development, given its simple yet very powerful object model. While many full-featured desktop applications have been successfully created using Windows Forms, the fact of the matter is that this programming model is rather asymmetrical. Simply put, System.Windows.Forms.dll and System.Drawing.dll do not provide direct support for many additional technologies required to build a feature-rich desktop application. To illustrate this point, consider the ad hoc nature of GUI development before the release of WPF (e.g., .NET 2.0; see Table 27-1).

Table 27-1. .NET 2.0 Solutions to Desired Functionalities

Desired Functionality .NET 2.0 Solution

Building windows with controls Windows Forms

2D graphics support GDI+ (System.Drawing.dll)

3D graphics support DirectX APIs

Support for streaming video Windows Media Player APIs

Support for flow-style documents Programmatic manipulation of PDF files

As you can see, a Windows Forms developer must pull in types from a number of unrelated APIs and object models. While it is true that making use of these diverse APIs may look similar syntactically (it is just VB 2010 code, after all), you may also agree that each technology requires a radically different mind- set. For example, the skills required to create a 3D rendered animation using DirectX are completely different from those used to bind data to a grid. To be sure, it is very difficult for a Windows Forms programmer to master the diverse nature of each API.

■ Note Appendix A provides an introduction to Windows Forms and GDI+ application development.

Unifying Diverse APIs WPF (introduced with .NET 3.0) was purposely created to merge these previously unrelated programming tasks into a single unified object model. Thus, if you need to author a 3D animation, you have no need to manually program against the DirectX API (although you could), as 3D functionality is baked directly into WPF. To see how well things have cleaned up, consider Table 27-2, which illustrates the desktop development model ushered in as of .NET 3.0.

1166 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Table 27-2. .NET 3.0 Solutions to Desired Functionalities

Desired Functionality .NET 3.0 and Higher Solution

Building forms with controls WPF

2D graphics support WPF

3D graphics support WPF

Support for streaming video WPF

Support for flow-style documents WPF

The obvious benefit here is that .NET programmers now have a single, symmetrical API for all common GUI programming needs. Once you become comfortable with the functionality of the key WPF assemblies and the grammar of XAML, you'll be amazed how quickly you can create very sophisticated UIs.

Providing a Separation of Concerns via XAML Perhaps one of the most compelling benefits is that WPF provides a way to cleanly separate the look and feel of a Windows application from the programming logic that drives it. Using XAML, it is possible to define the UI of an application via XML markup. This markup (ideally generated using tools such as Microsoft Expression Blend) can then be connected to a managed code base to provide the guts of the program’s functionality.

■ Note XAML is not limited to WPF applications! Any application can use XAML to describe a tree of .NET objects, even if they have nothing to do with a visible user interface. For example, the Windows Workflow Foundation API uses a XAML-based grammar to define business processes and custom activities.

As you dig into WPF, you may be surprised how much flexibility “desktop markup” provides. XAML allows you to define not only simple UI elements (buttons, grids, list boxes, etc.) in markup, but also 2D and 3D graphical data, animations, data binding logic, and multimedia functionality (such as video playback). For example, defining a circular button control that animates a company logo requires just a few lines of markup. As shown in Chapter 31, WPF controls can be modified through styles and templates, which allow you to change the overall look and feel of an application with minimum fuss and bother. Unlike Windows Forms development, the only compelling reason to build a custom WPF control library is if you need to change the behaviors of a control (e.g., add custom methods, properties, or events; subclass an existing control to override Overridable members). If you simply need to change the look and feel of a control (again, such as a circular animated button), you can do so entirely through markup.

1167 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Providing an Optimized Rendering Model GUI toolkits such as Windows Forms, VB6, or MFC preformed all graphical rendering requests (including the rendering of UI elements such as buttons and list boxes) using a low level, API (GDI), which has been part of the Windows OS for years. GDI provides adequate performance for typical business applications or simple graphical programs; however, if a UI application needed to tap into high performance graphics, DirectX was required. The WPF programming model is quite different in that GDI is not used when rendering graphical data. All rendering operations (e.g., 2D graphics, 3D graphics, animations, UI widget renderings buttons, list boxes) now make use of the DirectX API. The first obvious benefit is that your WPF applications will automatically take advantage of hardware and software optimizations. As well, WPF applications can tap into very rich graphical services (blur effects, anti-aliasing, transparency, etc.) without the complexity of programming directly against the DirectX API.

■ Note Although WPF does push all rendering requests to the DirectX layer, I don't want to suggest that a WPF application will perform as fast as building an application using unmanaged C++ and DirectX directly. If you are build a desktop application that requires the fastest possible execution speed (such as a 3D video game), unmanaged C++ and DirectX are still the best approach.

Simplifying Complex UI Programming To recap the story thus far, Windows Presentation Foundation (WPF) is an API to build desktop applications that integrates various desktop APIs into a single object model and provides a clean separation of concerns via XAML. In addition to these major points, WPF applications also benefit from a very simple way to integrate services into your programs, which historically were quite complex to account for. Here is a quick rundown of the core WPF features: • A number of layout managers (far more than Windows Forms) to provide extremely flexible control over placement and reposition of content. • Use of an enhanced data-binding engine to bind content to UI elements in a variety of ways. • A built-in style engine, which allows you to define “themes” for a WPF application. • Use of vector graphics, which allows content to be automatically resized to fit the size and resolution of the screen hosting the application. • Support for 2D and 3D graphics, animations, and video and audio playback. • A rich typography API, such as support for XML Paper Specification (XPS) documents, fixed documents (WYSIWYG), flow documents, and document annotations (e.g., a Sticky Notes API). • Support for interoperating with legacy GUI models (e.g., Windows Forms, ActiveX, and Win32 HWNDs). For example, you can incorporate custom Windows Forms controls into a WPF application, and vice versa.

1168 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Now that you have some idea of what WPF brings to the table, let's turn our attention to the various types of applications that can be created using this API.

The Various Flavors of WPF The WPF API can be used to build a variety of GUI-centric applications that basically differ in their navigational structure and deployment models. The sections that follow present a high-level walk through each option.

Traditional Desktop Applications The first (and most familiar) option is to use WPF to build a traditional executable assembly that runs on a local machine. For example, you could use WPF to build a text editor, painting program, or multimedia program such as a digital music player, photo viewer, and so forth. Like any other desktop applications, these *.exe files can be installed using traditional means (setup programs, Windows Installer packages, etc.) or via ClickOnce technology to allow desktop applications to be distributed and installed via a remote web server. Programmatically speaking, this type of WPF application will make use (at a minimum) of the Window and Application types, in addition to the expected set of dialog boxes, toolbars, status bars, menu systems, and other UI elements. Now, you can certainly use WPF to build your basic, bland business application that does not support any bells and whistles, but WPF really shines when you do incorporate such features. Consider Figure 27-1, which shows a WPF sample desktop application for viewing patient records in a medical environment.

1169 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-1. This WPF desktop application makes use of several WPF APIs

Sadly, the printed page does not show the full feature set of this window. Note that the upper right of the main window is displaying a real time graph of the patient's sinus rhythm. If you click on Patient Details button on the lower right, several animations take place to flip, rotate and transform the UI to the following look and feel (Figure 27-2).

1170 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-2. Transformations and animations are very simple under WPF

Could you build this same application without WPF? Absolutely. However, the amount of code— and the complexity of the code—would be much higher.

■ Note This example application can be downloaded (with source code) from the office WPF web site, http://windowsclient.net. Here you will find numerous WPF (and Windows Forms) sample projects, technology walkthroughs and forums.

1171 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Navigation-Based WPF Applications WPF applications can optionally choose to make use of a navigation-based structure, which makes a traditional desktop application take on the basic behavior of a web browser application. Using this model, you can build a desktop *.exe that provides a “forward” and “back” button that allows the end user to move back and forth between various UI displays called pages. The application itself maintains a list of each page and provides the necessary infrastructure to navigate between them, pass data across pages (similar to a web-based application variable), and maintain a history list. By way of a concrete example, consider Windows Explorer (see Figure 27-3), which makes use of such functionality. Notice the navigation buttons (and history list) mounted on the upper-left corner of the window.

Figure 27-3. A navigation-based desktop program

Regardless of the fact that a WPF desktop application can take on a weblike navigational structure, understand that this is simply a UI design issue. The application itself is still little more than a local executable assembly running on a desktop machine, and it has little to do with a web application beyond a slightly similar look and feel. Programmatically speaking, this type of WPF application is constructed using classes such as Application, Page, NavigationWindow, and Frame.

XBAP Applications WPF also allows you to build applications that can be hosted within a web browser. This flavor of WPF application is termed an XAML browser application, or XBAP. Under this model, the end user navigates to a given URL, at which point the XBAP (which is essentially a collection of Page objects) is transparently downloaded and installed to the local machine. Unlike a traditional ClickOnce installation for an executable application, however, the XBAP program is hosted directly within the browser and adopts the browser’s intrinsic navigational system. Figure 27-4 illustrates an XBAP program in action (specifically, the ExpenseIt WPF sample program that ships with the .NET Framework 4.0 SDK).

1172 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-4. XBAP programs are downloaded to a local machine and hosted within a web browser

The benefit of an XBAP is that it allows you to create sophisticated UIs which are much more expressive than a typical web page built with HTML and JavaScript. An XBAP Page object can make use of the same WPF services as a desktop WPF application, including animations, 2D and 3D graphics, themes and whatnot. In effect, the web browser is just a container for WPF Page objects, and is not displaying ASP.NET web pages. However, given that these Page objects are deployed to a remote web server, XBAPs can be easily versioned and updated without the need to redeploy executables to the user's desktop. Like a traditional web program, you can simply update the Page objects in the web server, and the user will get the 'latest and greatest' when they access the URL. One downside to this flavor of WPF is that XBAPs must be hosted within Microsoft Internet Explorer or Firefox web browsers. If you are deploying XBAPs across a company intranet, browser compatibility should not be a problem, given that system administrators can play dictator regarding which browser should be installed on users’ machines. However, if you want the outside world to make use of your XBAP, it is not possible to ensure each end user is making use of Internet Explorer/Firefox, and therefore some external users may not be able to view your WPF XBAP. Another issue to be aware of is the machine which is viewing an XBAP must have a local installation of the .NET framework, as the Page objects will be using the same .NET assemblies as an application running natively on the machine. Given this particular point, XBAPs are limited to Windows operating systems and thus cannot be viewed on a system running Mac OS X or Linux.

1173 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

The WPF/Silverlight Relationship WPF and XAML also provide the foundation for a cross-platform, cross-browser WPF-based technology termed Silverlight. From a high level, you can consider Silverlight as a competitor to Adobe Flash, with the benefit of using VB 2010 and XAML rather than a new set of tools and languages. Silverlight is a subset of WPF functionality, which is used to build highly interactive plug-ins for a larger HTML-based web page. In reality, however, Silverlight is a completely unique distribution of the .NET platform, which ships with a "mini" CLR and "mini" version of the .NET base class libraries. Unlike an XBAP, the user's machine does not need a full installation of the .NET Framework. As long as the target machine has the Silverlight runtime installed, the browser will load the Silverlight runtime and display the Silverlight application automatically. Best of all, Silverlight plug-ins are not limited to the Windows operating systems! Microsoft has also created a Silverlight runtime for Mac OS X.

■ Note The Mono project (see Appendix B) provides an open source version of Silverlight for Linux based OSs named Moonlight. This API, in conjunction with Silverlight, provides the fabric for a true cross-platform model for extremely rich web pages.

With Silverlight, you are able to build extremely feature-rich (and interactive) web applications. For example, like WPF, Silverlight has a vector-based graphical system, animation support, and multimedia support. Furthermore, you are able to incorporate a subset of the .NET base class library into your applications. This subset includes a number of WPF controls, LINQ support, generic collection types, web service support, and a healthy subset of mscorlib.dll (file I/O, XML manipulation, etc.).

■ Note This edition of the text does not address Silverlight; however, a majority of your WPF knowledge will map directly to the construction of Silverlight web plug-ins. If you are interested in learning more about this API, check out www.silverlight.net.

Investigating the WPF Assemblies Regardless of which type of WPF application you wish to build, WPF is ultimately little more than a collection of types bundled within .NET assemblies. Table 27-3 describes the core assemblies used to build WPF applications, each of which must be referenced when creating a new project (as you would hope, Visual Studio 2010 and Expression Blend WPF projects automatically reference the required assemblies).

1174 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Table 27-3. Core WPF Assemblies

Assembly Meaning in Life

PresentationCore.dll This assembly defines numerous types that constitute the foundation of the WPF GUI layer. For example, this assembly contains support for the WPF Ink API (for programming against stylus input for Pocket PCs and Tablet PCs), several animation primitives, and numerous graphical rendering types.

PresentationFramework.dll This assembly contains a majority of the WPF controls, the Application and Window classes, and support for interactive 2D geometries. As well, this library provides basic functionality to read and write XAML documents at runtime.

System.Xaml.dll This assembly provides namespaces which allow you to program against a XAML document at runtime. By and large, this library is only useful if you are authoring WPF support tools or need absolute control over XAML at runtime.

WindowsBase.dll This assembly defines types that constitute the infrastructure of the WPF API., including those representing WPF threading types, security types, various type converters, and support for dependency properties and routed events (described in Chapter 29).

Collectively, these assemblies define a number of new namespaces and hundreds of new .NET classes, interfaces, structures, enumerations, and delegates. While you should consult the .NET Framework 4.0 SDK documentation for complete details, Table 27-4 describes the role of some (but certainly not all) of the namespaces you should be aware of.

Table 27-4. Core WPF Namespaces

Namespace Meaning in Life

System.Windows This is the root namespace of WPF. Here you will find core classes (such as Application and Window) that are required by any WPF desktop project.

System.Windows.Controls Contains all of the expected WPF widgets, including types to build menu systems, tool tips, and numerous layout managers.

System.Windows.Data Types to work with the WPF data binding engine, as well as support for data binding templates.

System.Windows.Documents Contains types to work with the documents API, which allows you to integrate PDF style functionality into your WPF applications, via the XML Paper Specification (XPS) protocol.

1175 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Continued

Namespace Meaning in Life

System.Windows.Ink Support for the Ink API, which allows you to capture input from a stylus or mouse, respond to input gestures, and so forth. Very useful for Tablet PC program; however, any WPF can make use of this API.

System.Windows.Markup This namespace defines a number of types that allow XAML markup (and the equivalent binary format, BAML) to be parsed and processed programmatically.

System.Windows.Media This is the root namespace to several media-centric namespaces. Within these namespaces you will find types to work with animations, 3D rendering, text rendering, and other multimedia primitives.

System.Windows.Navigation This namespace provides types to account for the navigation logic employed by XAML browser applications (XBAPs) as well as standard desktop applications that require a navigational page model.

System.Windows.Shapes Defines classes which allow you to render interactive 2D graphics that automatically respond to mouse input.

To begin your journey into the WPF programming model, you’ll examine two members of the System.Windows namespace that are commonplace to any traditional desktop development effort: Application and Window.

■ Note If you are new to the development of desktop applications using the .NET platform, be aware that the System.Windows.Forms.* and System.Drawing.* assemblies are not related to WPF! These libraries represent the original .NET GUI toolkit, Windows Forms (see Appendix A).

The Role of the Application Class The System.Windows.Application class represents a global instance of a running WPF application. This class supplies a Run() method (to start the application), a series of events that you are able to handle in order to interact with the application’s lifetime (such as Startup and Exit), and a number of events that are specific to XAML browser applications (such as events that fire as a user navigates between pages). Table 27-5 details some of the key properties to be aware of.

1176 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Table 27-5. Key Properties of the Application Type

Property Meaning in Life

Current This Shared property allows you to gain access to the running Application object from anywhere in your code. This can be very helpful when a window or dialog box needs to gain access to the Application object that created it, typically to access application wide variables and functionality.

MainWindow This property allows you to programmatically get or set the main window of the application.

Properties This property allows you to establish and obtain data that is accessible throughout all aspects of a WPF application (windows, dialog boxes, etc.).

StartupUri This property gets or sets a URI that specifies a window or page to open automatically when the application starts.

Windows This property returns a WindowCollection type, which provides access to each window created from the thread that created the Application object. This can be very helpful when you wish to iterate over each open window of an application and alter its state (such as minimizing all windows).

Constructing an Application Class Any WPF application will need to define a class that extends Application. Within this class, you will define your program's entry point (the Main() method), which creates an instance of this subclass and typically handles the Startup and Exit events. You will build a full example project in just a moment, but here is a quick example:

'Define the global application object 'for this WPF program. Class MyApp Inherits Application _ Shared Sub Main(ByVal args As String()) ' Create the application object. Dim app As New MyApp()

' Register the Startup / Exit events. AddHandler app.Startup, AddressOf AppStartUp AddHandler app.Exit, AddressOf AppExit End Sub End Class

1177 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Within the Startup handler, you will most often process any incoming command line arguments and launch the main window of the program. The Exit handler, as you would expect, is where you can author any necessary shut down logic for the program (e.g., save user preferences, write to the Windows registry).

Enumerating the Application.Windows collection Another interesting property exposed by Application is Windows, which provides access to a collection representing each window loaded into memory for the current WPF application. Recall that as you create new Window objects, they are automatically added into the Application.Windows collection. Here is an example method that will minimize each window of the application (perhaps in response to a given keyboard gesture or menu option triggered by the end user):

Private Shared Sub MinimizeAllWindows() For Each wnd As Window In Application.Current.Windows wnd.WindowState = WindowState.Minimized Next End Sub

You’ll build a complete Application-derived type in an upcoming example. Until then, let’s check out the core functionality of the Window type and learn about a number of important WPF base classes in the process.

The Role of the Window Class The System.Windows.Window class represents a single window owned by the Application-derived class, including any dialog boxes displayed by the main window. Not surprisingly, Window has a series of parent classes, each of which brings more functionality to the table. Consider Figure 27-5, which shows the inheritance chain (and implemented interfaces) for System.Windows.Window as seen through the Visual Studio 2010 object browser.

1178 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-5. The hierarchy of the Window class

You’ll come to understand the functionality provided by many of these base classes as you progress through this chapter and the chapters to come. However, to whet your appetite, the following sections present a breakdown of the functionality provided by each base class (consult the .NET Framework 4.0 SDK documentation for full details).

The Role of System.Windows.Controls.ContentControl The direct parent of Window is ContentControl, which is quite possibly the most enticing of all WPF classes. This base class provides derived types with the ability to host a single piece of content, which, simply put, refers to the data placed within the interior of the control’s surface area via the Content property. The WPF content model makes it very simple to customize the basic look and feel of a content control. For example, when you think of a typical "button" control, you tend to assume that the content is a basic string literal (OK, Cancel, Abort, etc). If you are using XAML to describe a WPF control, and the value you wish to assign to the Content property can be captured as a simple string, you may set the Content property within the element’s opening definition as so (don't fret over the exact markup at this point):

1179 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

■ Note The Content property can also be set in VB 2010 code, which allows you to change the interior of a control at runtime.

However, content can be anything. For example, let's say you wish to have a "button" that has something more interesting than a simple string, perhaps a custom graphic and a blurb of text. In other UI frameworks such as Windows Forms, you would be required to build a custom control, which could entail quite a bit of code and a whole new class to maintain. With the WPF content model, there is no need to do so. When you wish to assign to the Content property to a value which cannot be captured as a simple array of characters, you are unable to assign the Content property using an attribute in the control’s opening definition. Rather, you must define the content data implicitly, within the element's scope. For example, this

contains a as content, which itself contains some unique data (an and , to be exact):

You can also make use of XAML's property-element syntax to set complex content. Consider the following functionally equivalent definition, which sets the Content property explicitly using property-element syntax (again, you’ll find more information on XAML later in this chapter, so don’t sweat the details just yet):

Do be aware that not every WPF control derives from ContentControl, and therefore not all controls supports this unique content model. As well, some WPF controls add a few refinements to the basic content model you have just examined. Chapter 28 will examine the role of WPF content in much more detail.

1180 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

The Role of System.Windows.Controls.Control Unlike ContentControl, all WPF controls share the Control base class as a common parent. This base class provides numerous core members that account for basic UI functionality. For example, Control defines properties to establish the control’s size, opacity, tab order logic, the display cursor, background color, and so forth. Furthermore, this parent class provides support for templating services. As explained in Chapter 31, WPF controls can completely change the way they render their appearance using templates and styles. Table 27-6 documents some key members of the Control type, grouped by related functionality.

Table 27-6. Key Members of the Control Type

Members Meaning in Life

Background, Foreground, BorderBrush, These properties allow you to set basic settings regarding how the BorderThickness, Padding, control will be rendered and positioned. HorizontalContentAlignment, VerticalContentAlignment

FontFamily, FontSize, FontStretch, These properties control various font-centric settings. FontWeight

IsTabStop, TabIndex These properties are used to establish tab order among controls on a window.

MouseDoubleClick, These events handle the act of double-clicking a widget. PreviewMouseDoubleClick

Template This property allows you to get and set the control’s template, which can be used to change the rendering output of the widget.

The Role of System.Windows.FrameworkElement This base class provides a number of members that are used throughout the WPF framework, such as support for storyboarding (used within animations) and support for data binding, as well as the ability to name a member (via the Name property), obtain any resources defined by the derived type, and establish the overall dimensions of the derived type. Table 27-7 hits the highlights.

1181 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Table 27-7. Key Members of the FrameworkElement Type

Members Meaning in Life

ActualHeight, ActualWidth, MaxHeight, These properties control the size of the derived type. MaxWidth, MinHeight, MinWidth, Height, Width

ContextMenu Gets or sets the pop-up menu associated with the derived type.

Cursor Gets or sets the mouse cursor associated with the derived type.

HorizontalAlignment, VerticalAlignment Gets or sets how the type is positioned within a container (such as a panel or list box).

Name Allows to you assign a name to the type, in order to access its functionality in a code file.

Resources Provides access to any resources defined by the type (see Chapter 30 for an examination of the WPF resource system).

ToolTip Gets or sets the tool tip associated with the derived type.

The Role of System.Windows.UIElement Of all the types within a Window’s inheritance chain, the UIElement base class provides the greatest amount of functionality. The key task of UIElement is to provide the derived type with numerous events to allow the derived type to receive focus and process input requests. For example, this class provides numerous events to account for drag-and-drop operations, mouse movement, keyboard input, and stylus input (for Pocket PCs and Tablet PCs). Chapter 29 digs into the WPF event model in detail; however, many of the core events will look quite familiar (MouseMove, KeyUp, MouseDown, MouseEnter, MouseLeave, etc.). In addition to defining dozens of events, this parent class provides a number of properties to account for control focus, enabled state, visibility, and hit testing logic, as shown in Table 27-8.

1182 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Table 27-8. Key Members of the UIElement Type

Members Meaning in Life

Focusable, IsFocused These properties allow you to set focus on a given derived type.

IsEnabled This property allows you to control whether a given derived type is enabled or disabled.

IsMouseDirectlyOver, IsMouseOver These properties provide a simple way to perform hit-testing logic.

IsVisible, Visibility These properties allow you to work with the visibility setting of a derived type.

RenderTransform This property allows you to establish a transformation that will be used to render the derived type.

The Role of System.Windows.Media.Visual The Visual class type provides core rendering support in WPF, which includes hit testing of rendered data, coordinate transformation, and bounding box calculations. In fact, the Visual class interacts with the underlying DirectX subsystem to actually draw data on the screen. As examined in Chapter 29, WPF provides three possible manners in which you can render graphical data, each of which differs in terms of functionality and performance. Use of the Visual type (and its children, such as DrawingVisual) provides the most lightweight way to render graphical data, but it also entails the greatest amount of manual code to account for all the required services. Again, more details to come in Chapter 29.

The Role of System.Windows.DependencyObject WPF supports a particular flavor of .NET properties termed dependency properties. Simply put, this approach allows a type to compute the value of a property based on the value of other properties. In order for a type to participate in this new property scheme, it will need to derive from the DependencyObject base class. In addition, DependencyObject allows derived types to support attached properties, which are a form of dependency property very useful when programming against the WPF data-binding model as well as when laying out UI elements within various WPF panel types. The DependencyObject base class provides two key methods to all derived types: GetValue() and SetValue(). Using these members, you are able to establish the property itself. Other bits of infrastructure allow you to “register” who can use the dependency/attached property in question. While dependency properties are a key aspect of WPF development, much of the time their details are hidden from view. Chapter 29 dives further into the details of the “new” property type.

The Role of System.Windows.Threading.DispatcherObject The final base class of the Window type (beyond System.Object, which I assume needs no further explanation at this point in the book) is DispatcherObject. This type provides one property of interest, Dispatcher, which returns the associated System.Windows.Threading.Dispatcher object. The Dispatcher

1183 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

class is the entry point to the event queue of the WPF application, and it provides the basic constructs for dealing with concurrency and threading. By and large, this is a lower-level class that can be ignored by the majority of your WPF applications.

Building a WPF Application without XAML Given all of the functionality provided by the parent classes of the Window type, it is possible to represent a window in your application by either directly creating a Window object or using this class as the parent to a strongly typed descendent. Let’s examine both approaches in the following code example. Although most WPF applications will make use of XAML, doing so is entirely optional. Anything that can be expressed in XAML can be expressed in code and (for the most part) vice versa. If you wish, it is possible to build a complete WPF project using the underlying object model and procedural code. To illustrate, let’s create a minimal but complete application without the use of XAML using the Application and Window classes directly. Begin by creating a new Console Application named WpfAppAllCode (don't worry, you will use the Visual Studio WPF project template later in this chapter). Next, access the Project | Add Reference dialog box and add a reference to WindowsBase.dll, PresentationCore.dll, System.Xaml.dll and PresentationFramework.dll. Now, update your initial VB 2010 file with the following code, which creates a window of modest functionality:

' A simple WPF application, written without XAML. Imports System.Windows Imports System.Windows.Controls

' In this first example, you are defining a single class type to ' represent the application itself and the main window. Class Program Inherits Application

_ Public Shared Sub Main(ByVal args As String()) ' Handle the Startup and Exit events, and then run the application. Dim app As New Program() AddHandler app.Startup, AddressOf AppStartUp AddHandler app.Exit, AddressOf AppExit

' Fires the Startup event. app.Run() End Sub

Private Shared Sub AppExit(ByVal sender As Object, ByVal e As ExitEventArgs) MessageBox.Show("App has exited") End Sub

Private Shared Sub AppStartUp(ByVal sender As Object, ByVal e As StartupEventArgs) ' Create a Window object and set some basic properties. Dim mainWindow As New Window() mainWindow.Title = "My First WPF App!" mainWindow.Height = 200 mainWindow.Width = 300

1184 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

mainWindow.WindowStartupLocation = WindowStartupLocation.CenterScreen mainWindow.Show() End Sub End Class

■ Note The Main() method of a WPF application must be attributed with the attribute, which ensures any legacy COM objects used by your application are thread-safe. If you do not annotate Main() in this way, you will encounter a runtime exception.

Note that the Program class extends the System.Windows.Application class. Within the Main() method, you create an instance of the application object and handle the Startup and Exit events using method group conversion syntax. Recall from Chapter 11 that this shorthand notation removes the need to manually specify the underlying delegates used by a particular event. Of course, if you wish, you can specify the underlying delegates directly by name. In the following modified Main() method, notice that the Startup event works in conjunction with the StartupEventHandler delegate, which can only point to methods taking an Object as the first parameter and a StartupEventArgs as the second. The Exit event, on the other hand, works with the ExitEventHandler delegate, which demands that the method pointed to take an ExitEventArgs type as the second parameter:

_ Public Shared Sub Main(ByVal args As String()) ' This time, specify the underlying delegates. Dim app As New Program() AddHandler app.Startup, AddressOf AppStartUp AddHandler app.Exit, AddressOf AppExit

' Fires the Startup event. app.Run() End Sub

In any case, the AppStartUp() method has been configured to create a Window object, establish some very basic property settings, and call Show() to display the window on the screen in a modeless fashion (the ShowDialog() method can be used to launch a modal dialog). The AppExit() method simply makes use of the WPF MessageBox class to display a diagnostic message when the application is being terminated. Before you compile and run the project, you may want to set the entry point of the application. To do so, go to the project’s properties and then select the Application tab. Select the Startup object drop- down, choose Sub Main from the list, and save the changes. Now if you run the project you will find a very simple main window that can be minimized, maximized, and closed. To spice things up a bit, you need to add some user interface elements. Before you do, however, you should refactor your code base to account for a strongly typed and well-encapsulated Window-derived class.

1185 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Creating a Strongly Typed Window Currently, the Application-derived class directly creates an instance of the Window type upon application startup. Ideally, you would create a class deriving from Window in order to encapsulate its appearance and functionality. Assume that you have created the following class definition within your current WpfAppAllCode application (if you place this class in a new VB 2010 file, be sure to import the System.Windows namespace):

Class MainWindow Inherits Window

Public Sub New(ByVal windowTitle As String, ByVal windowHeight As Integer, ByVal windowWidth As Integer) Me.Title = windowTitle Me.WindowStartupLocation = WindowStartupLocation.CenterScreen Me.Height = windowHeight Me.Width = windowWidth End Sub End Class

You can now update your Startup event handler to simply directly create an instance of MainWindow:

Private Shared Sub AppStartUp(ByVal sender As Object, ByVal e As StartupEventArgs) ' Create a MainWindow object. Dim wnd As New MainWindow("My better WPF App!", 200, 300) wnd.Show() End Sub

Once the program is recompiled and executed, the output is identical. The obvious benefit is that you now have a strongly typed window class to build upon.

■ Note When you create a Window (or Window-derived) object, it will automatically be added to the windows collection of the Application class (via some constructor logic found in the Window class itself). You can use the Application.Windows property to iterate over the list of Window objects currently in memory.

Creating a Simple User Interface Adding a UI element to a Window in VB 2010 code will involve the following basic steps: 1. Define a member variable to represent the control. 2. Configure the control’s look and feel upon Window construction. 3. Assign the control to the inherited Content property, or alternatively, as a parameter to the inherited AddChild() method.

1186 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Recall that the WPF control content model demands that the Content property is set only once. Of course, a Window that only contained a single UI control would be quite useless. Therefore, in almost every case, the "single piece of content" that is assigned to the Content property is, in reality, a layout manager, such as DockPanel, Grid, Canvas, or StackPanel. Within the layout manager, you can have any combination of internal controls, including other nested layout managers. (Read more on this aspect of WPF development in Chapter 28.) For now, you will add a single Button control to your Window derived class. When you click the button, you will close the current window, which will indirectly terminate the application, as you have no other windows in memory. Ponder the following update to the MainWindow class (be sure you have imported System.Windows.Controls to gain access to the Button class):

Class MainWindow Inherits Window

' Our UI element. Private btnExitApp As New Button()

Public Sub New(ByVal windowTitle As String, ByVal windowHeight As Integer, ByVal windowWidth As Integer) ' Configure button and set the child control. AddHandler btnExitApp.Click, AddressOf btnExitApp_Clicked btnExitApp.Content = "Exit Application" btnExitApp.Height = 25 btnExitApp.Width = 100

' Set the content of this window to a single button. Me.Content = btnExitApp

' Configure the window. Me.Title = windowTitle Me.WindowStartupLocation = WindowStartupLocation.CenterScreen Me.Height = windowHeight Me.Width = windowWidth Me.Show() End Sub

Private Sub btnExitApp_Clicked(ByVal sender As Object, ByVal e As RoutedEventArgs) ' close the window Me.Close() End Sub End Class

Notice that the Click event of the WPF Button works in conjunction with a delegate named RoutedEventHandler, which begs the question, what is a routed event? You’ll examine the details of the WPF event model in the next chapter; for the time being, simply understand that targets of the RoutedEventHandler delegate must supply an Object as the first parameter and a RoutedEventArgs as the second. In any case, once you recompile and run this application, you will find the customized window shown in Figure 27-6. Notice that your button is automatically placed in the dead center of the window’s client area; this is the default behavior when content is not placed within a WPF panel type.

1187 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-6. A Simple WPF application writen in 100% VB 2010 code

Interacting with Application Level Data Recall that the Application class defines a property named Properties, which allows you to define a collection of name/value pairs via a type indexer. Because this indexer has been defined to operate on type System.Object, you are able to store any sort of item within this collection (including your custom classes), to be retrieved at a later time using a friendly moniker. Using this approach, it is simple to share data across all windows in a WPF application. To illustrate, you will update the current Startup event handler to check the incoming command- line arguments for a value named /GODMODE (a common cheat code for many PC video games). If you find this token, you will establish a Boolean value set to True within the properties collection of the same name (otherwise you will set the value to False). Sounds simple enough, but how are you going to pass the incoming command-line arguments (typically obtained from the Main() method) to your Startup event handler? One approach is to call the Shared Environment.GetCommandLineArgs() method. However, these same arguments are automatically added to the incoming StartupEventArgs parameter and can be accessed via the Args property. That being said, here is the first update to the current code base:

Private Shared Sub AppStartUp(ByVal sender As Object, ByVal e As StartupEventArgs) ' Check the incoming command-line arguments and see if they ' specified a flag for /GODMODE. Application.Current.Properties("GodMode") = False

For Each arg As String In e.Args If arg.ToLower() = "/godmode" Then Application.Current.Properties("GodMode") = True Exit For End If Next ' Create a MainWindow object. Dim wnd As New MainWindow("My better WPF App!", 200, 300) End Sub

Application-wide data can be accessed from anywhere within the WPF application. All you are required to do is obtain an access point to the global application object (via Application.Current) and investigate the collection. For example, you could update the Click event handler of the Button as so:

1188 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Private Sub btnExitApp_Clicked(ByVal sender As Object, ByVal e As RoutedEventArgs) ' Did user enable /godmode? If CBool(Application.Current.Properties("GodMode")) Then MessageBox.Show("Cheater!") End If

Me.Close() End Sub

With this, if the end user launches our program as follows:

WpfAppAllCode.exe /godmode he or she will see our shameful message box displayed when terminating the application.

■ Note Recall that you can supply command line arguments within Visual Studio. Simply double click on the Properties icon within Solution Explorer, click the Debug tab from the resulting editor, and enter /godmode within the "Command line arguments" editor.

Handling the Closing of a Window Object End users can shut down a window using numerous built-in system-level techniques (e.g., clicking the “X” close button on the window’s frame) or by indirectly calling the Close() method in response to some user interaction element (e.g., File ➤ Exit). In either case, WPF provides two events that you can intercept to determine if the user is truly ready to shut down the window and remove it from memory. The first event to fire is Closing, which works in conjunction with the CancelEventHandler delegate. This delegate expects target methods to take System.ComponentModel.CancelEventArgs as the second parameter. CancelEventArgs provides the Cancel property, which when set to True will prevent the window from actually closing (this is handy when you have asked the user if he really wants to close the window or if perhaps he would like to save his work first). If the user did indeed wish to close the window, CancelEventArgs.Cancel can be set to False. This will then cause the Closed event to fire (which works with the System.EventHandler delegate), making it the point at which the window is about to be closed for good. Update the MainWindow class to handle these two events by adding these code statements to the current constructor:

Public Sub New(ByVal windowTitle As String, ByVal windowHeight As Integer, ByVal windowWidth As Integer) ... AddHandler Me.Closing, AddressOf MainWindow_Closing AddHandler Me.Closed, AddressOf MainWindow_Closed End Sub

1189 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Now, implement the corresponding event handlers as so:

Private Sub MainWindow_Closing(ByVal sender As Object, ByVal e As System.ComponentModel.CancelEventArgs) ' See if the user really wants to shut down this window. Dim msg As String = "Do you want to close without saving?" Dim result As MessageBoxResult = MessageBox.Show(msg, "My App", MessageBoxButton.YesNo, MessageBoxImage.Warning)

If result = MessageBoxResult.No Then ' If user doesn't want to close, cancel closure. e.Cancel = True End If End Sub

Private Sub MainWindow_Closed(ByVal sender As Object, ByVal e As EventArgs) MessageBox.Show("See ya!") End Sub

Now, run your program and attempt to close the window, either by clicking the "X" icon on the upper right of the window or by clicking the button control. You should see the following confirmation dialog (Figure 27-7).

Figure 27-7. Trapping the Closing event of a Window

If you click the Yes button, the application will terminate; however, clicking the No button will keep the window in memory.

Intercepting Mouse Events The WPF API provides a number of events you can capture in order to interact with the mouse. Specifically, the UIElement base class defines a number of mouse-centric events such as MouseMove, MouseUp, MouseDown, MouseEnter, MouseLeave, and so forth. Consider, for example, the act of handling the MouseMove event. This event works in conjunction with the System.Windows.Input.MouseEventHandler delegate, which expects its target to take a System.Windows.Input.MouseEventArgs type as the second parameter. Using MouseEventArgs (like a Windows Forms application), you are able to extract out the (x, y) position of the mouse and other relevant details. Consider the following partial definition:

1190 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Public Class MouseEventArgs Inherits InputEventArgs

... Public Function GetPosition(ByVal relativeTo As IInputElement) As Point Public ReadOnly Property LeftButton() As MouseButtonState Public ReadOnly Property MiddleButton() As MouseButtonState Public ReadOnly Property MouseDevice() As MouseDevice Public ReadOnly Property RightButton() As MouseButtonState Public ReadOnly Property StylusDevice() As StylusDevice Public ReadOnly Property XButton1() As MouseButtonState Public ReadOnly Property XButton2() As MouseButtonState End Class

■ Note The XButton1 and XButton2 properties allow you to interact with "extended mouse buttons" (such as the "next" and "previous" buttons found on some mouse controls). These are often used to interact with a browser's history list to navigate between visited pages.

The GetPosition() method allows you to get the (x, y) value relative to a UI element on the window. If you are interested in capturing the position relative to the activated window, simply pass in this. Handle the MouseMove event in the constructor of your MainWindow class like so:

Public Sub New(windowTitle As String, windowHeight As Integer, windowWidth As Integer) ... AddHandler Me.MouseMove, AddressOf MainWindow_MouseMove End Sub

Here is an event handler for MouseMove that will display the location of the mouse in the window’s title area (notice you are translating the returned Point type into a text value via ToString()):

Private Sub MainWindow_MouseMove(ByVal sender As Object, ByVal e As System.Windows.Input.MouseEventArgs) ' Set the title of the window to the current X,Y of the mouse. Me.Title = e.GetPosition(Me).ToString() End Sub

Intercepting Keyboard Events Processing keyboard input is also very straightforward. UIElement defines a number of events that you can capture to intercept keypresses from the keyboard on the active element (e.g., KeyUp, KeyDown). The KeyUp and KeyDown events both work with the System.Windows.Input.KeyEventHandler delegate, which expects the target’s second event handler to be of type KeyEventArgs, which defines several public properties of interest:

1191 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Public Class KeyEventArgs Inherits KeyboardEventArgs

... Public ReadOnly Property IsDown() As Boolean Public ReadOnly Property IsRepeat() As Boolean Public ReadOnly Property IsToggled() As Boolean Public ReadOnly Property IsUp() As Boolean Public ReadOnly Property Key() As Key Public ReadOnly Property KeyStates() As KeyStates Public ReadOnly Property SystemKey() As Key End Class

To illustrate, handle the KeyDown event in the constructor of MainWindow (just like you did for the previous events) and implement the following event handler that changes the content of the button with the currently pressed key, use this code:

Private Sub MainWindow_KeyDown(sender As Object, e As System.Windows.Input.KeyEventArgs) ' Display key press on the button. btnExitApp.Content = e.Key.ToString() End Sub

As a finishing touch, double click on the Properties icon of the Solution Explorer, and under the Application tab, set the Output Type setting to Windows Application. This will prevent the console window from launching in the background of your WPF application. Figure 27-8 shows the final product of your first WPF program.

Figure 27-8. Your first WPF program, 100% XAML free

At this point in the chapter, WPF might look like nothing more than yet another GUI framework that is providing (more or less) the same services as Windows Forms, VB6, or MFC. If this were in fact the case, you might question the need for yet another UI toolkit. To truly see what makes WPF so unique requires an understanding of the XML-based grammar, XAML.

■ Source Code The WpfAppAllCode project is included under the Chapter 27 subdirectory.

1192 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Building a WPF Application using Only XAML A typical WPF application will not be composed exclusively of code, as you did in this first example. Rather, your VB 2010 code files will be paired with a related XAML source file, and together they represent the entirety of a given Window or Application, as well as other class types we have not yet examined such as UserControl and Page. This approach is termed the code file approach to building a WPF application, and you will make use of this technique extensively throughout the remainder of the books WPF coverage. However, before you do, the next example will illustrate how to build a WPF application using nothing but XAML files. While this "100% XAML" approach is not recommended, it will help you clearly understand how blobs of markup are transformed into a corresponding VB 2010 code base, and ultimately, a .NET assembly.

■ Note This next example will make use of a number of XAML techniques we have not yet formally examined, so don't sweat the details. You may wish to simply load the solution files into a text editor and follow along; however, don't use Visual Studio 2010 to do so! Some of the markup in this sample contains markup that cannot be displayed in the Visual Studio XAML designers.

In general, XAML files will contain markup that describes the look and feel of the window , while the related VB 2010 code files contain the implementation logic. For example, the XAML file for a Window might describe the overall layout system, the controls within that layout system, and specify the names of various event handlers. The related VB 2010 file would contain the implementation logic of these event handlers and any custom code required by the application. Extensible Application Markup Language, or XAML, is an XML-based grammar that allows you to define the state (and, to some extent, the functionality) of a tree of .NET objects through markup. While XAML is frequently used when building UIs with WPF, in reality it can be used to describe any tree of nonabstract .NET types (including your own custom types defined in a custom .NET assembly), provided each supports a default constructor. As you will see, the markup within a *.xaml file is transformed into a full-blown object model. Because XAML is an XML-based grammar, we gain all the benefits and drawbacks XML affords us. On the plus side, XAML files are very self-describing (as any XML document should be). By and large, each element in an XAML file represents a type name (such as Button, Window, or Application) within a given .NET namespace. Attributes within the scope of an opening element map to properties (Height, Width, etc.) and events (Startup, Click, etc.) of the specified type. Given the fact that XAML is simply a declarative way to define the state of an object, it is possible to define a WPF widget via markup or procedural code. For example, the following XAML

can be represented programmatically as follows:

1193 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

' Defining the same WPF Button in VB 2010 code. Dim btnClickMe As New Button() btnClickMe.Height = 40 btnClickMe.Width = 100 btnClickMe.Content = "Click Me"

On the downside, XAML can be verbose and is (like any XML document) case sensitive, thus complex XAML definitions can result in a good deal of markup. Most developers will not need to manually author a complete XAML description of their WPF applications. Rather, the majority of this task will (thankfully) be relegated to development tools such as Visual Studio 2010, Microsoft Expression Blend, or any number of third-party products. Once the tools generate the basic markup, you can go in and fine-tune the XAML definitions by hand if necessary.

Defining MainWindow in XAML While tools can generate a good deal of XAML on your behalf, it is important for you to understand the basic workings of XAML syntax and how this markup is eventually transformed into a valid .NET assembly. To illustrate XAML in action, in the next example you’ll build a WPF application using nothing more than a pair of *.xaml files. The first Window-derived class (MainWindow) was defined in VB 2010 as a class type that extends the System.Windows.Window base class. This class contains a single Button object that calls a registered event handler when clicked. Defining this same Window type in the grammar of XAML can be achieved as so (assume this markup has been defined in a file named MainWindow.xaml):

1194 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

First of all, notice that the root element makes use of the Class attribute, which is used to specify the name of the VB 2010 class that will be generated when this XAML file is processed. Also notice that the Class attribute is prefixed with the x: tag prefix. If you look within the opening element, you'll see that this XML tag prefix is assigned to the string "http://schemas.microsoft.com/ winfx/2006/xaml" to build an XML namespace declaration. You will understand the details of these XML namespace definitions a bit later in the chapter, but for now, just be aware that any time you want to make reference to an item defined by the "http://schemas.microsoft.com/winfx/2006/xaml" XAML namespace, you must prefix the x: token. Within the scope of the start tag, you have specified values for the Title, Height, Width, and WindowsStartupLocation attributes, which are a direct mapping to properties of the same name supported by the System.Windows.Window class in the PresentationFramework.dll assembly. Next up, notice that within the scope of the window’s definition, you have authored markup to describe the look and feel of a Button object that will be used to implicitly set the Content property of the window. Beyond setting up the variable name (using the x:Name XAML token) and its overall dimensions, you have also handled the Click event of the Button type by assigning the method to delegate to when the Click event occurs. The final aspect of this XAML file is the element, which allows you to author event handlers and other methods of this class directly within an *.xaml file. As a safety measure, the code itself is wrapped within a CDATA scope to prevent XML parsers from attempting to directly interpret the data (although this is not strictly required for the current example). It is important to point out that authoring functionality within a element is not recommended. Although this “single-file approach” isolates all the action to one location, inline code does not provide a clear separation of concerns between UI markup and programming logic. In most WPF applications, implementation code will be found within a related VB 2010 file (which you will do eventually).

Defining the Application Object in XAML Remember that XAML can be used to define in markup any nonabstract .NET class that supports a default constructor. Given this, you could most certainly define your application object in markup as well. Consider the following content within a new file, MyApp.xaml:

Here, you might agree, the mapping between the Application-derived VB 2010 class type and its XAML description is not as clear-cut as was the case for our MainWindow’s XAML definition. Specifically, there does not seem to be any trace of a Main() method. Given that any .NET executable must have a program entry point, you are correct to assume it is generated at compile time, based in part on the StartupUrl property. The value assigned to StartupUrl represents which XAML resource to display when the application starts up. Although the Main() method is automatically created at compile time, you are free to use the element to capture other VB 2010 code blocks. For example, if you wanted to display a message when your program shuts down, you could handle the Exit event and implement it as so:

1195 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

]]>

Processing the XAML Files using msbuild.exe At this point, you are ready to transform our markup into a valid .NET assembly. However, you cannot directly use the VB 2010 compiler to do so! To date, the VB 2010 compiler does not have a native understanding of XAML markup. However, the msbuild.exe command-line utility does understand how to transform XAML into VB 2010 code and compile this code on the fly when it is informed of the correct *.targets files. Msbuild.exe is a tool that will compile .NET code based on the instructions contained within an XML based build script. As it turns out, these build script files contain the exact same sort of data that is found in the *.vbproj file generated by Visual Studio! Therefore, it is possible to compile a .NET program at the command-line using msbuild.exe or using Visual Studio 2010 itself.

■ Note A full examination of the msbuild.exe utility is beyond the scope of this chapter. If you’d like to learn more, perform a search for the topic “MSBuild” in the .NET Framework 4.0 SDK documentation.

Here is a very simple build script, SimpleXamlApp.vbproj, which contains just enough information to inform msbuild.exe how to transform your XAML files into a related VB 2010 code base:

SimpleXamlApp SimpleXamlApp winexe

1196 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

■ Note This *.vbproj file cannot be loaded directly into Visual Studio 2010, as it only contains the minimal instructions necessary to build our application at the command line.

The element is used to specify some basic aspects of the build, such as the root namespace, the name of the resulting assembly, and the output type (the equivalent of the /target:winexe option of vbc.exe). The first specifies the set of external assemblies to reference with the current build, which, as you can see, are the core WPF assemblies examined earlier in this chapter. The second is much more interesting. Notice that the element’s Include attribute is assigned to the *.xaml file that defines our application object. The ’s Include attribute can be used to list each of the remaining *.xaml files that define the windows (and pages, which are often used when building XAML browser applications) processed by the application object. However, the "magic" of this build script is the final elements. Here, you are referencing two *.targets files, each of which contains numerous other instructions used during the build process. The Microsoft.WinFX.targets file contains the necessary build settings to transform the XAML definitions into equivalent VB 2010 code files, while Microsoft.VisualBasic contains data to interact with the VB 2010 compiler itself. In any case, at this point you can use a Visual Studio 2010 Command Prompt to process your XAML data with msbuild.exe. To do so, change to the directory containing your MainWindow.xaml, MyApp.xaml and SimpleXamlApp.vbproj files, and enter the following command: msbuild SimpleXamlApp.vbproj

Once the build process has completed, you will find that your working directory now contains a \bin and \obj subdirectory (just like a Visual Studio project). If you were to open the \bin\Debug folder, sure enough, you will find a new .NET assembly named SimpleXamlApp.exe. If you open this assembly into ildasm.exe, you can see that (somehow) your XAML has been transformed into a valid executable application (see Figure 27-9).

1197 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-9. Transforming XAML markup into a .NET assembly? Interesting . . .

And if you run your program by double clicking on the executable, you will see your main window launch on the screen.

Transforming Markup into a .NET Assembly To understand exactly how your markup was transformed into a .NET assembly, you need to dig a bit deeper into the msbuild.exe process and examine a number of compiler-generated files, including a particular binary resource embedded within the assembly at compile time. The first task is to learn how your *.xaml files are transformed into a corresponding VB 2010 code base.

Mapping the Window XAML Data to VB 2010 Code The *.targets files specified in a msbuild script contain numerous instructions to translate XAML elements into VB 2010 code. When msbuild.exe processed your *.vbproj file, it produced two files with the form *.g.vb (where g denotes autogenerated) that were saved into the \obj\Debug directory. Based on the names of your *.xaml file names, the VB 2010 files in question are MainWindow.g.vb and MyApp.g.vb. If you open the MainWindow.g.vb file into a text editor, you will find a class named MainWindow, which extends the Window base class. The name of this class is a direct result of the x:Class attribute in the start tag. This class also contains a member variable of type System.Windows.Controls.Button, named btnExitApp. In this case, the name of the control is based on the x:Name attribute value within the opening

declaration. This class also contains the handler for the button's Click event, btnExitApp_Clicked(). Here is a partial listing of this compiler generated file:

1198 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Partial Public Class MainWindow Inherits System.Windows.Window Implements System.Windows.Markup.IComponentConnector

Friend WithEvents btnExitApp As System.Windows.Controls.Button

Sub btnExitApp_Clicked(ByVal sender As Object, ByVal e As RoutedEventArgs) Me.Close() End Sub ... End Class

This class defines a private member variable of type Boolean (named _contentLoaded), which was not directly accounted for in the XAML markup. This data member is used to determine (and ensure) the content of the window is assigned only once:

Public Partial Class MainWindow Inherits System.Windows.Window Implements System.Windows.Markup.IComponentConnector

' This member variable will be explained soon enough. Private _contentLoaded As Boolean ... End Class

Notice that the compiler generated class also explicitly implements the WPF IComponentConnector interface defined in the System.Windows.Markup namespace. This interface defines a single method called Connect(), which has been implemented to prep each control defined in the markup and rig up the event logic as specified within the original MainWindow.xaml file. Before the method completes, the _contentLoaded member variable is set to True. Here is the crux of the method:

Sub System_Windows_Markup_IComponentConnector_Connect(ByVal connectionId As Integer, ByVal target As Object) Implements System.Windows.Markup.IComponentConnector.Connect

If (connectionId = 1) Then Me.btnExitApp = CType(target, System.Windows.Controls.Button)

#ExternalSource("..\..\MainWindow.xaml",11) AddHandler Me.btnExitApp.Click, New System.Windows.RoutedEventHandler(AddressOf Me.btnExitApp_Clicked)

#End ExternalSource Return End If Me._contentLoaded = True End Sub

Last but not least, the MainWindow class also defines and implements a method named InitializeComponent(). You might expect that this method contains code that sets up the look and feel of each control by setting various properties (Height, Width, Content, etc). However, this is not the case!

1199 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

How then do the controls take on the correct UI? The logic with InitializeComponent() resolves the location of an embedded assembly resource that is named identical to the original *.xaml file:

Public Sub InitializeComponent() Implements System.Windows.Markup.IComponentConnector.InitializeComponent If_contentLoaded Then Return End If _contentLoaded = True Dim resourceLocater As New System.Uri("/SimpleXamlApp;component/mainwindow.xaml", System.UriKind.Relative) System.Windows.Application.LoadComponent(Me, resourceLocater) End Sub

At this point, the question becomes, what exactly is this embedded resource?

The Role of BAML When msbuild.exe processed our *.vbproj file, it generated a file taking a *.baml file extension. The full name of this file is named based on the initial MainWindow.xaml file, therefore you should see a file called MainWindow.baml in the \obj\Debug folder. As you might have guessed from the name, Binary Application Markup Language (BAML) is a compact, binary representation of the original XAML data. This *.baml file is embedded as a resource (via a generated *.g.resources file) into the compiled assembly. You can verify this for yourself by opening your assembly using reflector.exe, as shown in Figure 27-10.

Figure 27-10. Viewing the embedded *.baml resource using Reflector

This BAML resource contains all of the data needed to establish the look and feel of the UI widgets (again, such as the Height and Width properties). In fact, if you open the *.baml file into Visual Studio 2010, you can see traces of the initial XAML attributes (see Figure 27-11).

1200 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-11. BAML is a compact, binary version of the initial XAML markup

The important take-away here is to understand that a WPF application contains within itself a binary representation (the BAML) of the markup. At runtime, this BAML will be plucked out of the resource container and used to make sure all windows and controls are initialized to the correct look and feel. Also, remember that the name of these binary resources are identical to the name of the standalone *.xaml files you authored. However, this does not imply in any way that you must distribute the loose *.xaml files with your compiled WPF program! Unless you build a WPF application that will dynamically load and parse *.xaml files at runtime, you will never need to ship the original markup.

Mapping the Application XAML Data to VB 2010 Code The final piece of the autogenerated code to examine is the MyApp.g.vb file. Here, you see your Application-derived class with a proper Main() entry point method. The implementation of this method calls InitializeComponent() on the Application-derived type, which, in turn, sets the StartupUri property, allowing each of the objects to establish its correct property settings based on the binary XAML definition.

Namespace SimpleXamlApp

Partial Public Class MyApp Inherits System.Windows.Application

Sub AppExit(ByVal sender As Object, ByVal e As ExitEventArgs) MessageBox.Show("App has exited") End Sub

_ Public Sub InitializeComponent() AddHandler [Exit], New System.Windows.ExitEventHandler(AddressOf Me.AppExit) Me.StartupUri = New System.Uri("MainWindow.xaml", System.UriKind.Relative) End Sub

1201 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

_ Public Shared Sub Main() Dim app As New SimpleXamlApp.MyApp() app.InitializeComponent() app.Run() End Sub End Class End Namespace

XAML-to-Assembly Process Summary So far, you have created a full-blown .NET assembly using nothing but two XAML files and a related build script. As you have seen, msbuild.exe leverages auxiliary settings defined within the *.targets file to process the XAML files (and generate the *.baml) for the build process. While these gory details happen behind the scenes, Figure 27-12 illustrates the overall picture regarding the compile-time processing of *.xaml files.

Figure 27-12. The XAML-to-assembly compile-time process

Hopefully you now have a much better idea how XAML data is used to build a .NET application. At this point, you are ready to take a look at the syntax and semantics of XAML itself.

■ Source Code The WpfAppAllXaml project can be found under the Chapter 27 subdirectory.

1202 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Understanding The Syntax of WPF XAML Production level WPF applications will typically make use of dedicated tools to generate the necessary XAML. As helpful as these tools are, it is a very good idea to have an understanding of the overall structure of XAML markup.

Introducing Kaxaml When you are first learning the grammar of XAML, it can be very helpful to use a free tool named kaxaml. You can obtain this popular WPF XAML editor/parser from the following web site: http://www.kaxaml.com

Kaxaml is helpful in that it has no clue about VB 2010 source code, event handlers or implementation logic and is a much more straightforward way to test XAML snippets than using a full- blown Visual Studio 2010 WPF project template. As well, kaxaml has a number of integrated tools, such as a color chooser, XAML snippet manager, and even a "XAML scrubber" option that will format your XAML based on your settings. When you first open kaxaml, you will find simple markup for a control:

Like a Window, a Page contains various layout managers and controls. However, unlike a Window, Page objects cannot run as standalone entities. Rather, they must be placed inside of a suitable host such as a NavigationWindow, Frame or a web browser (and in that case, you have just made an XBAP!). The good news is that you can type identical markup within a or scope.

■ Note If you change the and elements in the kaxaml markup window to and , you can press the F5 key to load a new window onto the screen.

As an initial test, enter the following markup into the XAML pane at the bottom of the tool:

1203 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

You should now see your page render at the upper part of the kaxaml editor (Figure 27-13).

Figure 27-13. Kaxaml is a very helpful (and free) tool used to learn the grammar of XAML

As you work with kaxaml, remember that this tool does not allow you to author any markup that entails code compilation (however, using x:Name is allowed). This includes defining a x:Class attribute (for specifying a code file), entering event handler names in markup, or using any XAML keywords that also entail code compilation (such as FieldModifier or ClassModifier). Any attempt to do so will result in a markup error.

XAML XML Namespaces and XAML "Keywords" The root element of a WPF XAML document (such as a , , or definition) will almost always make reference to two predefined XML namespaces:

1204 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

The first XML namespace, http://schemas.microsoft.com/winfx/2006/xaml/presentation, maps a slew of WPF .NET namespaces for use by the current *.xaml file (System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Ink, System.Windows.Media, System.Windows.Navigation, etc.). This one-to-many mapping is actually hard-coded within the WPF assemblies (WindowsBase.dll, PresentationCore.dll, and PresentationFramework.dll) using the assembly-level attribute. Here is one such listing, which essentially imports System.Windows:

If you load these WPF assemblies into reflector.exe, you can view these mappings firsthand. For example, if you select the PresentationCore.dll assembly (see Figure 27-14), and press the Space key, you will see numerous instances of the attribute.

Figure 27-14. The http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace maps to the core WPF namespaces

1205 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

The second XML namespace, http://schemas.microsoft.com/winfx/2006/xaml, is used to include XAML-specific "keywords" (for lack of a better term) as well as the inclusion of the System.Windows.Markup namespace:

One rule of any well-formed XML document (remember, XAML is an XML-based grammar) is that the opening root element designates one XML namespace as the primary namespace, which typically is the namespace that contains the most commonly used items. If a root element requires the inclusion of additional secondary namespaces (as seen here), they must be defined using a unique tag prefix (to resolve any possible name clashes). As a convention, the prefix is simply x; however, this can be any unique token you require, such as XamlSpecificStuff:

The obvious downside of defining wordy XML namespace prefixes is you would be required to type XamlSpecificStuff each time your XAML file needs to refer to one of the items defined within this XAML-centric XML namespace . Given that XamlSpecificStuff requires many additional keystrokes, just stick with x. In any case, beyond the x:Name, x:Class and x:Code keywords, the http://schemas.microsoft. com/winfx/2006/xaml XML namespace also provides access to additional XAML keywords, the most common of which are shown in Table 27-9.

Table 27-9. XAML Keywords

XAML Keyword Meaning in Life

x:Array Represents a .NET array type in XAML.

x:ClassModifier Allows you to define the visibility of the VB 2010 class (Friend or Public) denoted by the Class keyword.

x:FieldModifier Allows you to define the visibility of a type member (Friend, Public, Private, or Protected) for any named subelement of the root (e.g., a within a element). A named element is defined using the Name XAML keyword.

x:Key Allows you to establish a key value for an XAML item that will be placed into a dictionary element.

1206 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

XAML Keyword Meaning in Life x:Name Allows you to specify the generated VB 2010 name of a given XAML element. x:Null Represents a null reference (i.e., Nothing in VB 2010). x:Static Allows you to make reference to a Shared member of a type. x:Type The XAML equivalent of the VB GetType operator (it will yield a System.Type based on the supplied name). x:TypeArguments Allows you to establish an element as a generic type with a specific type parameter (e.g., List(Of Integer) vs. List(Of Boolean)).

In addition to these two necessary XML namespace declarations, it is possible, and sometimes necessary, to define additional tag prefixes in the opening element of a XAML document. You will typically do so whenever you need to describe in XAML a .NET class defined in an external assembly. For example, say you have built a few custom WPF controls and packaged them in a library named MyControls.dll. Now, if you wish to create a new Window that uses these controls, you can establish a custom XML namespace that maps to your library using the clr-namespace and assembly tokens. Here is some example markup that creates a tag prefix named myCtrls, which can be used to access members in your library:

The clr-namespace token is assigned to the name of the .NET namespace in the assembly, while the assembly token is set to the friendly name of the external *.dll assembly. You can use this syntax for any external .NET library you wish to manipulate in markup.

Controlling Class and Member Variable Declarations You will see many of these keywords in action where required in the chapters to come; however, by way of a simple example, consider the following XAML definition that makes use of the ClassModifier and FieldModifier keywords as well as x:Name and x:Class (remember that kaxaml.exe will not allow you to make use of any XAML keyword that entails code compilation, such as x:Code, x:FieldModifier, or x:ClassModifier):

1207 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

By default, all VB 2010/XAML type definitions are Public, while members default to Friend. However, based on your XAML definition, the resulting autogenerated file contains a Friend class type with a Public Button type:

Partial Friend Class MainWindow Inherits System.Windows.Window Implements System.Windows.Markup.IComponentConnector

Public WithEvents myButton As System.Windows.Controls.Button ... End Class

XAML Elements, XAML Attributes and Type Converters Once you have established your root element and any required XML namespaces, your next task is to populate the root with a child element. In a real-world WPF application, the child will be a layout manager (such as a Grid or StackPanel) which contains, in turn, any number of additional UI elements that describe the user interface. The next chapter examines these layout managers in detail, so for now just assume that your type will contain a single Button element. As you have already seen over the course of this chapter, XAML elements map to a class or structure type within a given .NET namespace, while the attributes within the opening element tag map to properties or events of the type. To illustrate, enter the following

definition into kaxaml:

Notice that the values assigned to each property have been captured as a simple text value. This may seem like a complete mismatch of data types because if you were to make this Button in VB 2010 code, you would not assign string objects to these properties but would make use of specific data types. For example, here is the same button authored in code:

1208 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Public Sub MakeAButton() Dim myBtn As New Button() myBtn.Height = 50 myBtn.Width = 100 myBtn.FontSize = 20 myBtn.Content = "OK!" myBtn.Background = New SolidColorBrush(Colors.Green) myBtn.Foreground = New SolidColorBrush(Colors.Yellow) End Sub

As it turns out, WPF ships with a number of type converter classes, which will be used to transform simple text values into the correct underlying data type. This process happens transparently (and automatically). While this is all well and good, there will be many times when you need to assign a much more complex value to a XAML attribute, which cannot be captured as a simple string. For example, let's say you want to build a custom brush to set the Background property of the Button. If you are building the brush in code, it is quite straightforward:

Public Sub MakeAButton() ... ' A fancy brush for the background. Dim fancyBrush As New LinearGradientBrush(Colors.DarkGreen, Colors.LightGreen, 45) myBtn.Background = fancyBrush myBtn.Foreground = New SolidColorBrush(Colors.Yellow) End Sub

How, however, can you represent your complex brush as a string? Well, you can't! Thankfully XAML provides a special syntax that can be used whenever you need to assign a property value to a complex object, termed property-element syntax.

Understanding XAML Property-Element Syntax Property-element syntax allows you to assign complex objects to a property. Here is an XAML description for a Button that makes use of a LinearGradientBrush to set its Background property:

Notice that within the scope of the and tags, you have defined a sub-scope named . Within this scope, you have defined a custom . (Don't worry about the exact code for the brush; you'll learn about WPF graphics in Chapter 30.)

1209 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Generally speaking, any property can be set using property-element syntax, that always breaks down to the following pattern:

While any property could be set using this syntax, if you can capture a value as a simple string, you will save yourself typing time. For example, here would be a much more verbose way to set the Width of your Button:

... 100

Understanding XAML Attached Properties In addition to property-element syntax, XAML defines a special syntax used to set a value to an attached property. Essentially, an attached property allows a child element to set the value for a property that is actually defined in a parent element. The general template to follow looks like this:

The most common use of attached property syntax is to position UI elements within one of the WPF layout managers classes (Grid, DockPanel, etc.). The next chapter dives into these panels in some detail; for now, enter the following in kaxaml:

Here, you have defined a Canvas layout manager that contains an Ellipse. Notice that the Ellipse is able to inform its parent (the Canvas) where to position its top/left position using attached property syntax. There are a few items to be aware of regarding attached properties. First and foremost, this is not an all-purpose syntax that can be applied to any property of any parent. For example, the following XAML cannot be parsed without error:

1210 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

In reality, attached properties are a specialized form of a WPF-specific concept termed a dependency property. Unless a property was implemented in a very specific manner, you cannot set its value using attached property syntax. You will explore dependency properties in a detail in Chapter 31.

■ Note Kaxaml, Visual Studio 2010, and Expression Blend all have IntelliSense, which will show you valid attached properties that can be set by a given element.

Understanding XAML Markup Extensions As explained, property values are most often represented using a simple string or via property-element syntax. There is, however, another way to specify the value of a XAML attribute, using markup extensions. Markup extensions allow a XAML parser to obtain the value for a property from a dedicated, external class. This can be very beneficial, given that some property values require a number of code statements to execute to figure out the value. Markup extensions provide a way to cleanly extend the grammar of XAML with new functionality. A markup extension is represented internally as a class that derives from MarkupExtension. Note that the chances of your ever needing to build a custom markup extension will be slim to none. However, a subset of XAML keywords (such as x:Array, x:Null, x:Static, and x:Type) are markup extensions in disguise! A markup extension is sandwiched between curly brackets, like so:

To see a markup extension in action, author the following into kaxaml:

1211 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Sun Kil Moon Red House Painters Besnard Lakes

First of all, notice that the definition has a new XML namespace declaration, which allows you to gain access to the System namespace of mscorlib.dll. With this XML namespace established, you first make use of the x:Static markup extension and grab values from OSVersion and ProcessorCount of the System.Environment class.

■ Note As you know, class-level members are called shared members in the vernacular of VB 2010. In terms of XAML, however, shared members are called static, and, therefore, we must use the {x:Static} token.

The x:Type markup extension allows you to gain access to the metadata description of the specified item. Here, you are simply assigning the fully qualified names of the WPF Button and System.Boolean types. The most interesting part of this markup is the ListBox. Here, you are setting the ItemsSource property to an array of strings declared entirely in markup! Notice how the x:Array markup extension allows you to specify a set of sub-items within its scope:

Sun Kil Moon Red House Painters Besnard Lakes

■ Note The previous XAML example is only used to illustrate a markup extension in action. As you will see in Chapter 28, there are much easier ways to populate ListBox controls!

1212 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Figure 27-15 shows the mark up of this in kaxaml.

Figure 27-15. Markup extensions allow you to set values via the functionality of a dedicated class

So! At this point, you have seen numerous examples that showcase each of the core aspects of XAML syntax. As you might agree, XAML is very interesting in that it allows you to describe a tree of .NET objects in a declarative manner. While this is extremely helpful when configuring graphical user interfaces, do remember that XAML can describe any type from any assembly provided it is a nonabstract type containing a default constructor.

Building a WPF Application using Code-Behind Files The first two examples of this chapter illustrated the extreme ends of building a WPF application, using all code or using all XAML. The recommended way to build any WPF application, however, is to use the code file approach. Under this model, the XAML files of your project contain nothing but the markup that describes the general state of your classes, while the code file contains the implementation details.

Adding a Code File for the MainWindow Class To illustrate, you will update the WpfAppAllXaml example to use code files. If you are following along, copy this entire folder and give it the name WpfAppCodeFiles. Now, create a new VB 2010 code file in this folder named MainWindow.xaml.vb (by convention, the name of a VB 2010 code-behind file takes the form *.xaml.vb). Add the following code to this new file:

1213 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

' MainWindow.xaml.vb Class MainWindow

Private Sub btnExitApp_Clicked(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Me.Close() End Sub End Class

Here, you have defined a partial class to contain the event handling logic that will be merged with the partial class definition of the same type in the *.g.vb file. Given that InitializeComponent() is defined within the MainWindow.g.vb file, your window’s constructor makes a call in order to load and process the embedded BAML resource. The MainWindow.xaml file will also need to be updated; this simply involves gutting all traces of the previous VB 2010 code:

Adding a Code File for the MyApp Class If desired, you could also build a code-behind file for your Application-derived type. Because most of the action takes place in the MyApp.g.vb file, the code within MyApp.xaml.vb is little more than the following:

' MyApp.xaml.vb Imports System.Windows Imports System.Windows.Controls

Namespace SimpleXamlApp

Partial Public Class Application

Private Sub AppExit(ByVal sender As Object, ByVal e As ExitEventArgs) MessageBox.Show("App has exited") End Sub

End Class

End Namespace

1214 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

The MyApp.xaml file now looks like so:

Processing the Code Files with msbuild.exe Before you recompile your files using msbuild.exe, you need to update our *.vbproj file to account for the new VB 2010 files to include in the compilation process, via the elements (shown in bold):

SimpleXamlApp SimpleXamlApp winexe

Once you pass our build script into msbuild.exe, you find once again the same executable assembly as the WpfAppAllXaml application. However, as far as development is concerned, you now have a clean partition of presentation (XAML) from programming logic (VB 2010). Given that this is the preferred method for WPF development, you’ll be happy to know that WPF applications created using Visual Studio 2010 always make use of the code-behind model just presented.

■ Source Code The WpfAppCodeFiles project can be found under the Chapter 27 subdirectory.

1215 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Building WPF Applications Using Visual Studio 2010 Over the course of this chapter you created examples using no-frills text editors, the command-line compiler, and kaxaml.exe. The reason for doing so, of course, was to focus on the core syntax of WPF applications without getting distracted by the bells and whistles of a graphical designer. Now that you have seen how to build WPF applications in the raw, let’s examine how Visual Studio 2010 can simplify the construction of WPF applications.

■ Note While Visual Studio 2010 does have some support for authoring complex XAML using the integrated designers, Expression Blend is a far better alternative to build the UI of your WPF applications. You will begin to examine Expression Blend in Chapter 28.

The WPF Project Templates The New Project dialog box of Visual Studio 2010 defines a set of WPF project workspaces, all of which are contained under the Window node of the Visual Basic root. Here, you can choose from a WPF Application, WPF User Control Library, WPF Custom Control Library, and WPF Browser Application (i.e., XBAP). To begin, create a new WPF Application named MyXamlPad (Figure 27-16).

Figure 27-16. The WPF project templates of Visual Studio 2010

1216 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Beyond setting references to each of the WPF assemblies (PresentationCore.dll, PresentationFramework.dll, and WindowsBase.dll), you will also be provided with initial Window and Application derived classes, making use of code files and a related XAML file. Consider Figure 27-17, which shows the Solution Explorer for this new WPF project.

Figure 27-17. The initial files of a WPF Application project

Exploring the WPF Designer Tools Visual Studio 2010 provides a Toolbox (which you can open via the View menu) that contains numerous WPF controls (Figure 27-18).

Figure 27-18. The Toolbox contains the WPF controls that can be placed on the designer surface

1217 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Using a standard mouse drag and drop, you can place any of these controls onto the Window's designer surface. As you do, the underlying XAML will be authored on your behalf. However, you can also manually type in your markup using the integrated XAML editor. As you can see in Figure 27-19, you do get IntelliSense support, which can help simplify the authoring of the markup.

Figure 27-19. The WPF Window designer

■ Note You can reposition the display panes of the visual designer using the buttons embedded within the splitter window, such as the Swap Panes button (indicated by the up/down arrows), the Horizontal and Vertical split buttons, and so on. Take a moment to find a configuration you are comfortable with.

1218 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Once you have placed controls onto your designer (which you will do in a moment), you can then make use of the Properties window to set property values for the selected control, as well as rig up event handlers for the selected control. By way of a simple test, drag a button control anywhere on your visual designer. Once you do, you will see that Visual Studio authored XAML similar to the following:

Now, use the Properties window to change the Background color of the Button using the integrated brush editor (Figure 27-20).

■ Note The Brush Editor of Expression Blend is very similar to the Visual Studio brush editor and will be examined in detail in Chapter 29.

Figure 27-20. The Properties window can be used to configure the UI of a WPF control

Once you have finished tinkering with the brush editor, check out the generated markup. It might look something like this:

1219 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

If you wish to handle events for a given control, you can also make use of the Properties window, but this time you need to click on the Events tab. Ensure that the button is selected on your designer, click on the Events tab, and locate the Click event. Once you do, double click directly on the Click event entry. This will cause Visual Studio 2010 to automatically build an event handler that takes the form:

NameOfControl_NameOfEvent

Since you did not rename your button, the Properties window shows it generated an event handler named button1_Click (see Figure 27-21).

Figure 27-21. Handling events using the visual designer

As well, Visual Studio 2010 generated the corresponding VB 2010 code in your window's code file. Here, you can add any sort of code that must execute when the button is clicked:

Class MainWindow Private Sub button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles button1.Click

End Sub End Class

You can also handle events directly in the XAML editor. By way of an example, place your mouse within the element and type in the MouseEnter event, followed by the equals sign. Once you do, you will see Visual Studio displays any compatible handlers in your code file, as well as the option. If you double click , the IDE will generate a fitting handler in your VB 2010 code file. Now that you have seen the basic tools used within Visual Studio 2010 to create WPF applications, let’s leverage this IDE to build an example program that illustrates the process of parsing XAML at runtime. Before you start, completely delete the markup describing the Button you just created and also delete the VB 2010 event handler code.

1220 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Designing the GUI of our Window The WPF API supports the ability to load, parse, and save XAML descriptions programmatically. Doing so can be quite useful in a variety of situations. For example, assume you have five different XAML files that describe the look and feel of a Window type. As long as the names of each control (and any necessary event handlers) are identical within each file, it would be possible to dynamically apply “skins” to the window (perhaps based on a startup argument passed into the application). Interacting with XAML at runtime revolves around the XamlReader and XamlWriter types, both of which are defined within the System.Windows.Markup namespace. To illustrate how to programmatically hydrate a Window object from an external *.xaml file, you will build an application that mimics the basic functionality of the kaxaml. While your application will certainly not be as feature-rich as kaxaml.exe, it will provide the ability to enter XAML markup, view the results, and save the XAML to an external file. To begin, update the initial XAML definition of your as:

■ Note The next chapter will dive into the details of working with controls and panels, so don’t fret over the details of the control declarations.

First of all, notice that you have replaced the initial with a type that contains a Button (named btnViewXaml) and a TextBox (named txtXamlData), and that the Click event of the Button type has been handled. Also notice that the Loaded and Closed events of the Window itself have been handled within the opening element. If you have used the designer to handle your events, you should find the following code in your MainWindow.xaml.vb file:

1221 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Partial Public Class MainWindow Private Sub btnViewXaml_Click(ByVal sender As Object, ByVal e As RoutedEventArgs) End Sub

Private Sub Window_Closed(ByVal sender As Object, ByVal e As EventArgs) End Sub

Private Sub Window_Loaded(ByVal sender As Object, ByVal e As RoutedEventArgs) End Sub End Class

Before continuing, be sure to import the following namespaces into your MainWindow.xaml.vb fMainWindow.xaml.vb file:

Imports System.IO Imports System.Windows.Markup

Implementing the Loaded Event The Loaded event of your main window is in charge of determining if there is currently a file named YourXaml.xaml in the folder containing the application. If this file does exist, you will read in the data and place it into the TextBox on the main window. If not, you will fill the TextBox with an initial default XAML description of an empty window (this description is the exact same markup as an initial window definition, except that you are using a rather than a ).

■ Note The string you are building to represent the key XML namespaces is a bit cumbersome to type, given the escape characters required for the embedded quotations, so type carefully.

Private Sub Window_Loaded(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) ' When the main window of the app loads, ' place some basic XAML text into the text block. If (File.Exists(System.Environment.CurrentDirectory + "\YourXaml.xaml")) Then txtXamlData.Text = File.ReadAllText("YourXaml.xaml") Else txtXamlData.Text = "

1222 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

WindowStartupLocation=""CenterScreen"">" & vbLf & "" & vbLf & "" & vbLf & "" End If End Sub

Using this approach, your application will be able to load the XAML entered in a previous session or supply a default block of markup if necessary. At this point, you should be able to run your program and find the display shown in Figure 27-22 within the TextBox type.

Figure 27-22. The first run of MyXamlPad.exe

Implementing the Button’s Click Event When you click the Button, you will first save the current data in the TextBox into the YourXaml.xaml file. At this point, you will read in the persisted data via File.Open() to obtain a Stream-derived type. This is necessary, as the XamlReader.Load() method requires a Stream-derived type (rather than a simple System.String) to represent the XAML to be parsed. Once you have loaded the XAML description of the you wish to construct, create an instance of System.Windows.Window based on the in-memory XAML and display the Window as a modal dialog:

Private Sub btnViewXaml_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) ' Write out the data in the text block to a local *.xaml file. File.WriteAllText("YourXaml.xaml", txtXamlData.Text)

' This is the window that will be dynamically XAML-ed. Dim myWindow As Window = Nothing

1223 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

' Open local *.xaml file. Try Using sr As Stream = File.Open("YourXaml.xaml", FileMode.Open)

' Connect the XAML to the Window object. myWindow = DirectCast(XamlReader.Load(sr), Window)

'Show window as a dialog and clean up myWindow.ShowDialog() myWindow.Close() myWindow = Nothing End Using

Catch ex As Exception MessageBox.Show(ex.Message) End Try End Sub

Note that you are wrapping much of our logic within a Try/Catch block. In this way, if the YourXaml.xaml file contains ill-formed markup, you can see the error of your ways within the resulting message box. For example, run your program, and purposely misspell by adding an extra letter P in the opening element or whatnot. If you click the button, you will see an error similar to Figure 27-23.

Figure 27-23. Catching markup errors

Implementing the Closed Event Finally, the Closed event of your Window type will ensure that the latest and greatest data in the TextBox is persisted to the YourXaml.xaml file:

1224 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Private Sub Window_Closed(ByVal sender As System.Object, ByVal e As System.EventArgs) ' Write out the data in the text block to a local *.xaml file. File.WriteAllText("YourXaml.xaml", txtXamlData.Text) End Sub

Testing the Application Now fire up your program and enter some XAML into your text area. Do be aware that (like kaxaml.exe) this program does not allow you to specify any code generation–centric XAML attributes (such as Class or any event handlers). As a test, enter the following XAML within your scope:

Once you click the button, you will see a window appear that renders your XAML definitions (or possibly you’ll see a parsing error in the message box—watch your typing!). Figure 27-24 shows possible output.

Figure 27-24. MyXamlPad.exe in action

Great! I am sure you can think of many possible enhancements to this application, but to do so you need to be aware of how to work with WPF controls and the panels that contain them. You will do so starting in the next chapter.

■ Source Code The MyXamlPad project can be found under the Chapter 27 subdirectory.

1225 CHAPTER 27 ■ INTRODUCING WINDOWS PRESENTATION FOUNDATION AND XAML

Summary Windows Presentation Foundation (WPF) is a user interface toolkit introduced since the release of .NET 3.0. The major goal of WPF is to integrate and unify a number of previously unrelated desktop technologies (2D graphics, 3D graphics, window and control development, etc.) into a single unified programming model. Beyond this point, WPF programs typically make use of Extendable Application Markup Language (XAML), which allows you to declare the look and feel of your WPF elements via markup. Recall that XAML allows you to describe trees of .NET objects using a declarative syntax. During this chapter’s investigation of XAML, you were exposed to several new bits of syntax including property- element syntax and attached properties, as well as the role of type converters and XAML markup extensions. While XAML is a key aspect for any production level WPF application, your first example of this chapter illustrated how you can build a WPF program using nothing but VB 2010 code. Next, you discovered how you could build a WPF program using nothing but XAML (this is not recommended; however, it was a useful learning exercise!). Finally, you learned about the use of "code files" which allow you to partition look-and-feel from functionality. The final example of this chapter gave you a chance to build a WPF application that allowed you to programmatically interact with XAML definitions using the XamlReader and XamlWriter classes. Along the way, you took a tour of the WPF designers of Visual Studio 2010.

1226