The earliest Windows UI applications were usually written in C by using the Win32 API. This was an exacting task, somewhat equivalent to writing code in assembly language. There was a tremendous amount of boilerplate code needed to do almost anything, and you had to know just what was going on because there was no higher-level library taking care of the housekeeping for you.

For example, the simple task of creating a window on the screen entailed calling a function that took no fewer than 12 parameters, as demonstrated here:

HWND WINAPI CreateWindowEx(
    DWORD dwExStyle, LPCTSTR lpClassName, LPCTSTR lpWindowName,
    DWORD dwStyle, int x, int y, int nWidth, int nHeight,
    HWND hWndParent, HMENU hMenu,
    HINSTANCE hInstance, LPVOID lpParam);

You can probably guess what some of the parameters mean (x and y are the initial position of the window, and nWidth and nHeight specify its size), but there are some obscure parameters and types here.

Creating applications by using the Win32 API often means copying an existing application to get all the boilerplate startup and housekeeping code, and then editing the business logic parts.

Microsoft’s first C++ user interface library was Microsoft Foundation Classes (MFC), initially released in 1992 and now at version 10. MFC provides a thin C++ wrapper around the Window APIs, but it does perform most of the tedious housekeeping for you.

MFC made it possible to create applications that looked like Microsoft Office and Windows Explorer, and which could interoperate with Office applications by using a complex technology called Object Linking and Embedding (OLE). MFC 9 introduced a number of new features including support for docking windows similar to those found in Microsoft Visual Studio, and a ribbon toolbar similar to that used in Microsoft Office.

MFC has been deprecated in favor of .NET, but there are many applications that still use it. Versions 7 through 9 were designed to help developers migrate to .NET, and so it is regarded as a legacy framework.

One drawback for MFC developers is that MFC has never had a UI designer in Visual Studio, although there are editors for icons, bitmaps, and other resources.

The first versions of .NET introduced a new UI library called Windows Forms (or WinForms), which was modeled on the Microsoft Visual Basic way of creating UIs, and (as the name implies) it was targeted at producing form-based applications. Because it was a .NET library, you could write Windows Forms applications in any .NET language.

Windows Forms applications can have multiple windows, menus and toolbars, dialogs, and all the other features that you would expect in a desktop Windows application.

A Windows Forms application consists of one or more windows called forms, and you typically develop it by dragging controls from a toolbox onto a form and then using the Properties editor to set control properties and event handlers. Windows Forms was the first time that C++ developers had a visual designer for creating UIs.

A form and its child controls are represented by objects in code, and the Visual Studio designer creates the code that will generate the desired layout at run time. Note that Visual Studio 2012 does not support Windows Forms for C++/CLI. It is possible that support might be added back in a later version, but for the time being if you want to use WinForms, you will need to use Visual Studio 2010.

Version 3.0 of the .NET Framework saw the release of Windows Presentation Foundation (WPF, code-named “Avalon”), which was intended to build on the success of Windows Forms as well as add extra functionality. Microsoft Silverlight is a subset of WPF for writing components to embed in webpages, and which provide the same kind of functionality as Adobe Flash.

Although you can use it to design form-based applications, WPF is very different from Windows Forms. Here are some of the main differences:

WPF can have a steep learning curve because it is intended as a professional graphics library with which developers can create any UI they want rather than a library that makes it easy to perform common tasks and build simple business applications.

Unfortunately, WPF isn’t easy to use from C++/CLI, because the language lacks support for partial classes, and this feature is essential if you are to work with XAML. I’m not entirely certain why this wasn’t added—it would certainly be possible—but it seems that Microsoft decided that it didn’t want C++/CLI used for modern front-end development. Whatever the reason, there has never been a C++/CLI designer for WPF in Visual Studio, and so there is no “WPF Application” project type.

Although Windows 8 fully supports the familiar Windows desktop environment, it also provides a new way of writing UI applications. Windows Store apps use a library called Windows RT (or WinRT) which provides a UI library that is aimed at touch devices and the style of interface made popular by the iPad and other tablets. It is called Windows Store because it is envisaged that developers will create applications and sell them online through Microsoft’s Windows Store, in common with the way that many other mobile platforms make content available.

Windows Store applications are very different to traditional Windows applications; they require a different approach to development, as you will see in this and Chapter 21.

So, Windows 8 supports two different styles of UI application: desktop and Windows Store. Note that they are completely separate. Among other things, this means that a Windows Store app won’t appear on the desktop and needs to run in the WinRT environment.

So, which UI library should you choose for your applications? For most developers, the choice will come down to Windows Forms, WPF, or Windows Store.

At this point, Win32 and MFC are really legacy technologies, and there are few times when you would consider starting a new project using either of them (although MFC does have some support for interacting with Office that the newer libraries don’t have)

If your application is going to have a traditional form-based UI, consisting mainly of text boxes and buttons, and doesn’t need fancy graphics, animation, or media file support, Windows Forms will be suitable. You will find everything you need in Visual Studio, including a visual designer.

If you want a desktop application but with the advanced features that WPF provides, that is the way to go, although if you are using C++, you will have to jump through quite a few hoops to get there.

And, if you want an up-to-date, tablet-style interface that will suit touch devices as well as desktop computers, consider Windows Store. Oh, and don’t let anyone tell you that Windows Store replaces WPF; they are designed for different types of application. I can’t see anyone producing a Windows Store-style version of Visual Studio any time soon!

In this section, I’ll list some of the major features of Windows Store apps. If you think of an app running on a typical tablet device or mobile phone, then you should be able to appreciate why these have been introduced.

This exercise shows you how to write the simplest of Windows Store apps, which in this case consists of a single screen and two controls. In Chapter 21, you see how to add more functionality, but this will show you the basics. Remember that to create and run Windows Store apps, you need to have Visual Studio 2012 installed on Windows 8. Be aware that you might also be prompted to get a developer license when you create your first project. For more information about developer licenses, read the sidebar at end of this exercise.

If you’re new to Windows 8 apps, you might be wondering how you get back to Visual Studio after you’ve performed testing. Moving the mouse to the lower-left corner of the screen displays the Start icon, which you can use to get back to the Start screen. When you get there, you’ll notice that your app has been added to the list of available applications on the right of the page, although it doesn’t look exciting because we haven’t defined any content for the tile yet.

If you click the tile you’ll be back at your app’s UI, and you will probably find that the TextBlock still shows “Hello, XAML!” This is because apps stay active after they’re started. I say “probably” because apps can be terminated if there is pressure on resources, in which case it would be restarted if you clicked it again.

If you decide that you don’t want the app to appear on the Start screen, right-click its tile and then, on the shortcut menu that appears, click Unpin From Start. Even if an application isn’t on the Start screen, you can always execute it by using the All Apps charm on the command bar.

When you create a Windows 8 app in Visual Studio, a lot of files are created. It is useful to know something about what they are, and in particular, which ones you can edit and which you should leave alone.

The following files are those that you can edit:

There are also a number of files that you shouldn’t touch. XAML applications make heavy use of partial classes, and the .g.cpp and .g.h files represent the parts of classes that are generated by Visual Studio:

XAML (Extensible Application Markup Language) is used in Windows RT and WPF to describe user interfaces. The idea behind XAML is that you create the user interface declaratively in XML, and the compiler then generates the code to create the UI at run time.

There are three ways by which you can create UIs:

XAML has a number of features that are especially useful for constructing UIs.

Using XAML for declarative UI layout separates the UI’s look and feel. This way, you can specify the name of a button’s click event handler without having to know in which language it is going to be implemented. This also makes it easy to separate the UI design and business logic implementation, making it possible for designers to work on the XAML without having to be concerned with the code.

XAML’s event handling lets you link control events to handler functions in code, but you can also make event links in XAML itself. For example, you can have a label display the text of whichever item you select in a list box or for the font size of a label to be determined by the position of a slider. This means that for many simple interactions between controls, you don’t need to write any code at all.

Using Control templates, you can define layout and visual behavior templates that can then be applied to controls across one or more applications. When combined with CSS-like styles and triggers that can change styles when events occur, you have a powerful way to create unique and responsive UIs. Template and style details can be defined as resources in XAML, which means that they can be reused easily. If placed in resource dictionaries, resources can be reused across projects.

Finally, data-binding is one of the most powerful features of XAML, making it possible for you to bind properties on objects to data that can come from a variety of sources. I have already mentioned one example, where the font size property of a control can be bound to the position of a slider. You can also bind to collections of objects, so that a list box can display an array of items, or you can bind to data retrieved from a data source.

In XAML, an object is represented by an XML element, and the object’s properties are defined by attributes. For example:

<Button Content="Click!" Click="Button_Click"/>

This element represents a Button object. It also sets its Content property and the name of the function used to handle the click event. It is easy to use custom classes from XAML, provided the runtime can locate the assembly containing the object code.

Relationships between objects are shown by nesting elements. For example, a ListBox can have a number of ListBoxItems, as demonstrated in the following:

<ListBox>
  <ListBoxItem>Item 1</ListBoxItem>
  <ListBoxItem>Item 2</ListBoxItem>
</ListBox>

If you want to interact with a control from code, it must have a name, and you do this using the x:Name attribute, as shown in this example:

<TextBlock x:Name="txtHello" ... />

The x: prefix indicates that this is the XAML Name attribute, because a control could have its own Name attribute. The prefix will be defined in one of the parent elements of the TextBlock, as shown here:

<Page
    ...
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" />

    <Grid ... >
        <TextBlock x:Name="TxtHello" ... />
    </Grid>
</Page>

In a Windows RT application, each page of a UI is represented by an object of a class derived from Page. The definition of this class is in a code-behind file, and the link between the XAML and the class is provided by the x:Class attribute:

<Page
    x:Class="HelloXaml.MainPage" ... >

XAML also makes use of markup extensions, which are attribute values enclosed in curly brackets, like this:

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}">

This syntax informs XAML that the attribute value isn’t simply text; it is normally used to create or manipulate objects.

A XAML UI is made up of controls. Everything is a control, from the top-level window to the image displayed on a button. Here’s an important principle: XAML UIs are constructed by nesting controls within one another, and there is only one control at the top level, which will be a container such as a Window or Page.

We can divide controls into two broad types: content controls (which can only contain one item) and items controls (which can contain more than one).

A content control can only contain one other item as its content; for instance, a Button can display a piece of text or an image, but this can be an items control. As an example, a Button can contain a StackPanel which holds both an image and some text, as shown in the following illustration:

Here is the XAML to create that button:

<Button HorizontalAlignment="Left" Margin="352,258,0,0"
        VerticalAlignment="Top" Height="120" Width="127">
    <StackPanel Orientation="Vertical">
        <TextBlock Text="Button" HorizontalAlignment="Center" />
        <Image Source="Assets/SmallLogo.png" Height="48" Width="75" />
    </StackPanel>
</Button>

You can see how the Button contains one item—a StackPanel—which contains a TextBlock and an Image stacked atop one another.

A selection of the most common content controls is shown in the following table:

A selection of the most common items controls is shown in the following table:

There is a special group of items controls that are used for UI layout. This group inherits from the Panel class. In both Windows Store and WPF applications, special controls are used to determine the layout of UI elements within a window or page. For instance, a Page might contain a Grid that will lay controls out in rows and columns, or a StackPanel that will create a vertical stack of elements. Separating out the container and layout functions affords greater freedom to UI designers because it is easy to create custom layouts if required. In this section, you’ll look at a few of the most common layout controls.

The StackPanel is the simplest layout control. It arranges its child controls into a stack, either vertically or horizontally depending on the value of the Orientation property. The following image shows three buttons in a vertical StackPanel:

The XAML for this layout is very simple:

<StackPanel Background="{StaticResource ApplicationPageBackgroundThemeBrush}"
    Orientation="Vertical">
    <Button Content="First" FontSize="24" />
    <Button Content="Second" FontSize="24" />
    <Button Content="Third" FontSize="24" />
</StackPanel>

Because no other properties have been specified for the StackPanel, the panel fills all the available space, and its child controls are left-justified. Here are the same controls with the Orientation changed to Horizontal:

The StackPanel still fills all the available space, but this time, it lays out its children horizontally. By default, the child controls are centered vertically.

If you have so many items in a StackPanel that they aren’t all visible at one time, you won’t see the controls that fall outside the bounds of the StackPanel, but all of the objects will still be created. The VirtualizingStackPanel manages this efficiently by only creating child controls when they’re visible.

The Grid is one of the most commonly used layouts. Items are arranged by row and column, and cells can have different sizes. You can specify the number of rows and columns as well as which cell a child control should occupy. The illustration that follows displays how three buttons look when displayed in a Grid.

The XAML for this layout shows some interesting features.

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}" >
    <Grid.RowDefinitions>
        <RowDefinition Height="60*" />
        <RowDefinition Height="40*"/>
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="60*" />
        <ColumnDefinition Width="40*" />
    </Grid.ColumnDefinitions>
    <Button Content="First" FontSize="24" Background="Blue" Grid.Row="0"
        HorizontalAlignment="Center"/>
    <Button Content="Second" FontSize="24" Background="Green" Grid.Row="1"
        HorizontalAlignment="Center"/>
    <Button Content="Third" FontSize="24" Background="Red" Grid.Column="1" Grid.Row="1"
        HorizontalAlignment="Center"/>
</Grid>

You can see how RowDefinition and ColumnDefinition elements are used to define the rows and columns in the grid. There are several ways to define the width and height, such as by using percentages or absolute values. In this case, the asterisk (*) denotes a proportion, so the widths of the two columns are distributed proportionally in the ratio 60:40. Like the StackPanel, there is no size specified for the Grid itself, so it fills all the available space. The other important concept shown by this example is the way in which the row and column values are specified for the buttons. This is done by using attached properties, which are explained in more detail in the sidebar that follows.

<Button x:Name="btn1" Grid.Row="1" .../>

Grid.SetRow(btn1, 1);

The VariableSizedWrapGrid is a variant on the Grid. It also lays items out in rows and columns but will automatically wrap items to the next row or column as necessary. This is obviously useful when the viewing area size changes, such as when switching your tablet from landscape to portrait mode. The following image shows five Button controls in a VariableSizedWrapGrid:

The XAML looks like this:

<VariableSizedWrapGrid Background="{StaticResource ApplicationPageBackgroundThemeBrush}
"
                           MaximumRowsOrColumns="3" Orientation="Horizontal" ItemWidth
="150
">
    <Button Content="First" FontSize="24" Background="Blue" HorizontalAlignment="Center
"/>
    <Button Content="Second" FontSize="24" Background="Green" HorizontalAlignment="Cent
er"/>
    <Button Content="Third" FontSize="24" Background="Red" HorizontalAlignment="Center"
/>
    <Button Content="Fourth" FontSize="24" Background="Cyan" HorizontalAlignment="Cente
r"/>
    <Button Content="Fifth" FontSize="24" Background="Magenta" HorizontalAlignment="Cen
ter"/>
</VariableSizedWrapGrid>

The horizontal orientation shows that this control will lay its children out in rows, and the MaximumRowsOrColums says that it will wrap at three items. To achieve a nice layout, each grid cell is 150 wide, and the buttons are centered within their cells. If you decide that you want a layout that looks more like the Windows 8 Start screen, you could change the XAML to the following:

<VariableSizedWrapGrid Background="{StaticResource ApplicationPageBackgroundThemeBrush}
"
    MaximumRowsOrColumns="3" Orientation="Horizontal" ItemWidth="150" ItemHeight="150"
 >
    <Button Content="First" FontSize="24" Background="Blue" HorizontalAlignment="Stretc
h"
        VerticalAlignment="Stretch"/>
    <Button Content="Second" FontSize="24" Background="Green" HorizontalAlignment="Stre
tch"
        VerticalAlignment="Stretch"/>
    <Button Content="Third" FontSize="24" Background="Red" HorizontalAlignment="Stretch
"
        VerticalAlignment="Stretch"/>
    <Button Content="Fourth" FontSize="24" Background="Cyan" HorizontalAlignment="Stret
ch"
        VerticalAlignment="Stretch"/>
    <Button Content="Fifth" FontSize="24" Background="Magenta" HorizontalAlignment="Str
etch"
        VerticalAlignment="Stretch"/>
</VariableSizedWrapGrid>

The difference is that both height and width have been set, and the horizontal and vertical alignments have been set to Stretch, so that the items will fill their respective cells. You can clearly see the difference in the following image:

The last layout control we’ll consider is the Canvas. With this control, you can specify absolute positions for its children, but it isn’t used as often as the others because it doesn’t adapt automatically to changing display conditions. Here is an example of some Buttons laid out on a Canvas:

Here’s the XAML for the layout:

<Canvas Background="{StaticResource ApplicationPageBackgroundThemeBrush}">
    <Button Content="First" FontSize="24" Canvas.Left="100" Canvas.Top="100" Background
="Blue"/>
    <Button Content="Second" FontSize="24" Canvas.Left="150" Canvas.Top="150"
        Background="Green"/>
    <Button Content="Third" FontSize="24" Canvas.Left="180" Canvas.Top="180" Background
="Red" />
</Canvas>

You can see that the positions of the Buttons are given by the Canvas.Left and Canvas.Top attached properties. The objects are displayed in the order in which they are declared, resulting in the third Button overlapping the second. If you want to specify the ordering explicitly, you can use the ZIndex property to determine the order in which elements will be rendered.

When creating a UI in XAML, you use attributes on controls to link events to event handling functions, such as in the following example:

<Button Content="Click!" Click="Button_Click"/>

Here, the Button’s click event is being handled by a function called Button_Click in the associated code-behind file. Recall the example of an event handler function in the HelloXaml that you saw earlier:

void HelloXaml::MainPage::Button_Click_1(Platform::Object^ sender,
   Windows::UI::Xaml::RoutedEventArgs^ e)

Every event handler has the same signature: the return type is void, the first argument is a handle to the object that raised the event, and the second is a handle to an object, of type RoutedEventArgs or one of its subclasses, which might hold information about the event. For example, handlers for keyboard events will be sent a KeyRoutedEventArgs object whose Key property indicates which key was pressed. In the case of simple click-type notifications, there is no other information, so you can ignore this argument.

The word “routed” in RoutedEventArgs refers to the fact that events can be routed to more than one control. Consider the example you saw earlier in the chapter, in which a Button’s content consisted of a StackPanel containing an Image and a TextBlock. If you click the Image, you’re actually clicking an Image on top of a StackPanel on top of a Button, and you probably want to handle this event in the Button’s click handler. The event is first passed to the Image. Then, it’s passed to its parent (the StackPanel), and so on, bubbling up the tree until it either reaches the top or someone says they’ve handled it.

Windows RT is a new runtime on top of the Windows kernel. It doesn’t use Win32: It is completely new. It covers the same functionality as Win32 (which was introduced in 1993!) but is object-oriented and written in C++.

The WinRT APIs contain a subset of the Win32 and COM APIs. You can use WinRT APIs from several languages, and language bindings are now called projections. There are currently three projections available: native (for C++), JavaScript, and .NET (for C# and VB.NET).

All WinRT objects support reflection through metadata, so they can be used from dynamic languages such as JavaScript. WinRT uses the same metadata format as the CLR, which makes it easier and faster to use WinRT APIs from .NET without having to use P/Invoke.

WinRT code compiles down to native code, which has no facility for including metadata. For this reason, the metadata for WinRT code resides in separate files with a .winmd extension. These are CLI assemblies containing only metadata, so you can inspect them by using the IL disassembler tool (ISDASM).

C++/CX is a lightweight set of extensions to C++, so there isn’t too much to cover in this section. To create an object, use the ref new keyword, as demonstrated in the following:

MyClass ^mc = ref new MyClass();

The caret (^) is the same symbol used for managed handles in C++/CLI, but these are different because they are pointing to unmanaged code. We need a handle here rather than a pointer because C++/CX objects are reference counted.

Observe the use of ref new to create objects. This is an example of a compound keyword, formed of two separate tokens, and is not simply new with a ref modifier.

public ref class MyClass
{
};

// MyClass.private.h
#pragma once
partial ref class MyClass  // use the 'partial' keyword
{
private:
    int _implementationDetail;
};

// MyClass.h
#pragma once
#include "MyClass.private.h"

ref class MyClass  // don't use the 'partial' keyword here
{
public:
    int GetDetail();
};

generic <typename T>
public ref class List
{
    property T item;
    ...
};

String ^s = "First string";

wchar_t *txt = L"Second string";
String ^s2 = ref new Platform::String(txt);

const wchar_t *txt = s->Data();

When building Windows Store apps you will find yourself working with a number of new namespaces. This final section summarizes the names and purposes of the main ones you need to know about.