PAGE APPLICATIONS

A Page is similar to a borderless Window. It doesn’t provide its own decorations (border, title bar, and so forth), but instead relies on its container to provide those elements.

Often a Page is hosted by a web browser, although the WPF Frame control can also display Page objects.

The following sections explain how you can use Page objects to build WPF applications.

Browser Applications

To make a XAML Browser Application (XBAP, pronounced ex-bap), select the File menu’s New Project command to display the New Project dialog box. On the Visual Basic ⇒ Windows tab, select WPF Browser Application, enter a project name, and click OK.

The new application begins with a single Page class named Page1. You can view and edit this Page exactly as you would view and edit a Window. Open the Solution Explorer and double-click the Page1.xaml entry to edit the Page’s controls. Double-click the Page1.xaml.vb entry to edit the Visual Basic code behind the Page.

To run the application, open the Debug menu and select Start Debugging. Internet Explorer should open and display the initial Page. Visual Studio is nicely integrated with this instance of Internet Explorer so you can set breakpoints in the code to stop execution and debug the code just as you can debug a Windows Forms application or a WPF Window application.

To add other Page classes to the application, open the Project menu and select Add Page. Enter a name for the class and click OK.

To display a Page in code, create a variable that refers to a new instance of the Page. Then use the current Page’s NavigationService object’s Navigate method to display the new Page.

The following code creates a new page of type Page2, and then uses the NavigationService object to display it:

Dim p2 As New Page2()
NavigationService.Navigate(p2)

Because the application is hosted inside a browser, there are several differences in the ways the user will interact with the application. Rather than displaying new forms and dialog boxes, the application will generally display new material within the same browser.

This design has several consequences. For example, the previous code creates a new instance of the Page2 class and displays it. If the user were to execute this same code later, it would create a second instance of the class and display it. Because these are two instances of the class, they do not have the same controls, so any changes the user makes (entering text, checking radio buttons, and so forth) are not shared between the two pages. When the second instance appears, the user may wonder where all of the previous selections have gone.

The program can prevent this confusion by using a single application-global variable to hold references to the Page2 instance. Every time the program needs to show this page, it can display the same instance. That instance will display the same control values so the user’s selections are preserved.

That approach solves one problem but leads to another. Because the application runs inside a browser, the browser’s navigation and history tools work with it. If you press the browser’s Back button, it will display the previous page. That part works relatively transparently, but every time the application uses NavigationService.Navigate to display a Page, that Page is added to the browser’s history.

To see why this is an issue, suppose the application has an initial Page that contains a button leading to a second Page. That Page has a button that navigates back to the first page. If the user moves back and forth several times, the browser’s history will be cluttered with entries such as Page 1, Page 2, Page 1, Page 2, and so forth. Although this represents the user’s actual path through the Pages, it isn’t very useful.

You can reduce clutter in the browser’s history by using the NavigationService object’s GoForward and GoBack methods whenever it makes sense. In this example, it would probably make sense for the second Page to use the GoBack method to return to the main page. Instead of creating a new entry in the history as the Navigate method does, GoBack moves back one position in the existing history. After several trips between the two Pages, the history will contain only those two Pages, one possibly available via the browser’s Back button and one possibly available via the browser’s Next button.

Example program BrowserApp demonstrates this technique. The program uses two Pages that provide buttons to navigate to each other. Both Pages also contain a text box where you can enter some text, just to verify that the values are preserved when you navigate between the pages.

The following code shows how the main Page navigates to the second Page. If the NavigationService can go forward, the code calls its GoForward method. If the NavigationService cannot go forward, the code uses its Navigate method to visit a new Page2 object.

Private Sub btnPage2_Click() Handles btnPage2.Click
    If NavigationService.CanGoForward Then
        NavigationService.GoForward()
    Else
        NavigationService.Navigate(New Page2())
    End If
End Sub

The following code shows how the second Page returns to the first. This code simply calls the NavigationService object’s GoBack method.

Private Sub btnBack_Click() Handles btnBack.Click
    Me.NavigationService.GoBack()
End Sub

Once you’ve built an XBAP, you can run it by pointing a web browser at the compiled xbap file. When I built the previous example program, the file BrowserApp.xbap was created in the project’s bin/Debug directory and the file successfully loaded in both Internet Explorer and Firefox.

Building a Page class is almost exactly the same as building a Window class. You use the same XAML editor and Visual Basic code behind the scenes. The main difference is in how you navigate between the application’s forms. In a WPF application, you create Window objects and use their Show or ShowDialog methods. In an XBAP, you create Page objects and use the NavigationService object’s navigation methods.

Frame Applications

Although Page objects normally sit inside a browser, the WPF Frame control can also host them. The program simply navigates the Frame control to a Page, and the rest works exactly as it does for an XBAP.

Example program FrameApp, which is available for download on the book’s website and shown in Figure 12-1, uses the following code to load a Page1 object into its Frame control:

FIGURE 12-1: The Frame control provides navigation between Page objects.

fraPages.Navigate(New Page1())

This example contains the same Page1 and Page2 classes used by the BrowserApp example program described in the previous section.

If an XBAP runs so easily in a browser, why would you want to host pages in a Frame control?

One reason is that you can place multiple frames within a Window to let the user view different pieces of information or perform different tasks at the same time. For example, you can display help in a separate frame, possibly in a separate Window.

If you build each frame’s contents in a separate XBAP, you can load the frames at run time. That makes replacing XBAPs to upgrade or change their contents easy.

The Frame control also provides simple browser-style navigation that uses Next and Back buttons and that may be easier for users to navigate in some situations. Microsoft’s web page “Top Rules for the Windows Vista User Experience” at http://msdn2.microsoft.com/Aa511327.aspx lists as Rule 7 “Use Windows Explorer-hosted, navigation-based user interfaces, provide a Back button.” That page argues that this style of interaction simplifies navigation even in traditional applications.

The Frame control gives you more control than a browser does. For example, it provides easier access to Page history. You can also determine a Frame control’s size, whereas you have no control over a browser’s size and position.

Displaying Page objects within a Frame control won’t make sense for every application, but for some it can be a useful technique.