Windows Phone

Programming Windows Phone 7 : The Standard Silverlight Files

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/24/2010 7:46:54 PM
With the project loaded in Visual Studio, take a look at the Solution Explorer for the project. You’ll see two pairs of skeleton files: App.xaml and App.xaml.cs, and MainPage.xaml and MainPage.xaml.cs. The App.xaml and MainPage.xaml files are Extensible Application Markup Language (XAML) files, while App.xaml.cs and MainPage.xaml.cs are C# code files. This peculiar naming scheme is meant to imply that the two C# code files are “code-behind” files associated with the two XAML files. They provide code in support of the markup. This is a basic Silverlight concept.

I want to give you a little tour of these four files. If you look at the App.xaml.cs file, you’ll see a namespace definition that is the same as the project name and a class named App that derives from the Silverlight class Application. Here’s an excerpt showing the general structure:

Example 1. Silverlight Project: SilverlightHelloPhone File: App.xaml.cs (excerpt)
namespace SilverlightHelloPhone
public partial class App : Application
public App()
. . .
. . .
. . .

All Silverlight programs contain an App class that derives from Application; this class performs application-wide initialization, startup, and shutdown chores. You’ll notice this class is defined as a partial class, meaning that the project should probably include another C# file that contains additional members of the App class. But where is it?

The project also contains an App.xaml file, which has an overall structure like this:

Example 2. Silverlight Project: SilverlightHelloPhone File: App.xaml (excerpt)
. . .

You’ll recognize this file as XML, but more precisely it is a XAML file, which is an important part of Silverlight programming. In particular, developers often use the App.xaml file for storing resources that are used throughout the application. These resources might include color schemes, gradient brushes, styles, and so forth.

The root element is Application, which is the Silverlight class that the App class derives from. The root element contains four XML namespace declarations. Two are common in all Silverlight applications; two are unique to the phone.

The first XML namespace declaration (“xmlns”) is the standard namespace for Silverlight, and it helps the compiler locate and identify Silverlight classes such as Application itself. As with most XML namespace declarations, this URI doesn’t actually point to anything; it’s just a URI that Microsoft owns and which it has defined for this purpose.

The second XML namespace declaration is associated with XAML itself, and it allows the file to reference some elements and attributes that are part of XAML rather than specifically Silverlight. By convention, this namespace is associated with a prefix of “x” (meaning “XAML”).

Among the several attributes supported by XAML and referenced with this “x” prefix is Class, which is often pronounced “x class.” In this particular XAML file x:Class is assigned the name SilverlightHelloPhone.App. This means that a class named App in the .NET SilverlightHelloPhone namespace derives from the Silverlight Application class, the root element. It’s the same class definition you saw in the App.xaml.cs file but with very different syntax.

The App.xaml.cs and App.xaml files really define two halves of the same App class. During compilation, Visual Studio parses App.xaml and generates another code file named App.g.cs. The “g” stands for “generated.” If you want to look at this file, you can find it in the \obj\Debug subdirectory of the project. The App.g.cs file contains another partial definition of the App class, and it contains a method named InitializeComponent that is called from the constructor in the App.xaml.cs file.

You’re free to edit the App.xaml and App.xaml.cs files, but don’t mess around with App.g.cs. That file is recreated when you build the project.

When a program is run, the App class creates an object of type PhoneApplicationFrame and sets that object to its own RootVisual property. This frame is 480 pixels wide and 800 pixels tall and occupies the entire display surface of the phone. The PhoneApplicationFrame object then behaves somewhat like a web browser by navigating to an object called MainPage.

MainPage is the second major class in every Silverlight program and is defined in the second pair of files, MainPage.xaml and MainPage.xaml.cs. In smaller Silverlight programs, it is in these two files that you’ll be spending most of your time.

Aside from a long list of using directives, the MainPage.xaml.cs file is very simple:

Example 3. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml.cs (excerpt)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using Microsoft.Phone.Controls;

namespace SilverlightHelloPhone

public partial class MainPage : PhoneApplicationPage
// Constructor
public MainPage()

The using directives for namespaces that begin with the words System.Windows are for the Silverlight classes; sometimes you’ll need to supplement these with some other using directives as well. The Microsoft.Phone.Controls namespace contains extensions to Silverlight for the phone, including the PhoneApplicationPage class.

Again, we see another partial class definition. This one defines a class named MainPage that derives from the Silverlight class PhoneApplicationPage. This is the class that defines the visuals you’ll actually see on the screen when you run the SilverlightHelloPhone program.

The other half of this MainPage class is defined in the MainPage.xaml file. Here’s the nearly complete file, reformatted a bit to fit the printed page, and excluding a section that’s commented out at the end, but still a rather frightening chunk of markup:

Example 4. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml (almost complete)
mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"
FontFamily="{StaticResource PhoneFontFamilyNormal}"
FontSize="{StaticResource PhoneFontSizeNormal}"
Foreground="{StaticResource PhoneForegroundBrush}"
SupportedOrientations="Portrait" Orientation="Portrait"

<!--LayoutRoot is the root grid where all page content is placed-->
<Grid x:Name="LayoutRoot" Background="Transparent">
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>

<!--TitlePanel contains the name of the application and page title-->
<StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
<TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION"
Style="{StaticResource PhoneTextNormalStyle}"/>
<TextBlock x:Name="PageTitle" Text="page name" Margin="9,-7,0,0"
Style="{StaticResource PhoneTextTitle1Style}"/>

<!--ContentPanel - place additional content here-->
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">

The first four XML namespace declarations are the same as in App.xaml. As in the App.xaml file, an x:Class attribute also appears in the root element. Here it indicates that the MainPage class in the SilverlightHelloPhone namespace derives from the Silverlight PhoneApplicationPage class. This PhoneApplicationPage class requires its own XML namespace declaration because it is not a part of standard Silverlight.

The “d” (for “designer”) and “mc” (for “markup compatibility”) namespace declarations are for the benefit of XAML design programs, such as Expression Blend and the designer in Visual Studio itself. The DesignerWidth and DesignerHeight attributes are ignored during compilation.

The compilation of the program generates a file name MainPage.g.cs that contains another partial class definition for MainPage (you can look at it in the \obj\Debug subdirectory) with the InitializeComponent method called from the constructor in MainPage.xaml.cs.

In theory, the App.g.cs and MainPage.g.cs files generated during the build process are solely for internal use by the compiler and can be ignored by the programmer. However, sometimes when a buggy program raises an exception, one of these files comes popping up into view. It might help your understanding of the problem to have seen these files before they mysteriously appear in front of your face. However, don’t try to edit these files to fix the problem! The real problem is probably somewhere in the corresponding XAML file.

In the root element of MainPage.xaml you’ll see settings for FontFamily, FontSize, and Foreground that apply to the whole page.

The body of the MainPage.xaml file contains several nested elements named Grid, StackPanel, and TextBlock in a parent-child hierarchy.

Notice the word I used: element. In Silverlight programming, this word has two related meanings. It’s an XML term used to indicate items delimited by start tags and end tags. But it’s also a word used in Silverlight to refer to visual objects, and in fact, the word element shows up in the names of two actual Silverlight classes.

Many of the classes you use in Silverlight are part of this important class hierarchy:

DependencyObject (abstract)
UIElement (abstract)
FrameworkElement (abstract)

Besides UIElement, many other Silverlight classes derive from DependencyObject. But UIElement has the distinction of being the class that has the power to appear as a visual object on the screen and to receive user input. (In Silverlight, all visual objects can receive user input.) Traditionally, this user input comes from the keyboard and mouse; on the phone, most user input comes from touch.

The only class that derives from UIElement is FrameworkElement. The distinction between these two classes is a historical artifact of the Windows Presentation Foundation. In WPF, it is possible for developers to create their own unique frameworks by deriving from UIElement. In Silverlight this is not possible, so the distinction is fairly meaningless.

One of the classes that derives from FrameworkElement is Control, a word more common than element in traditional graphical user-interface programming. Some objects commonly referred to as controls in other programming environments are more correctly referred to as elements in Silverlight.

Another class that derives from FrameworkElement is Panel, which is the parent class to the Grid and StackPanel elements you see in MainPage.xaml. Panels are elements that can host multiple children and arrange them in particular ways on the screen.

Another class that derives from FrameworkElement is TextBlock, the element you’ll use most often in displaying blocks of text up to about a paragraph in length. The two TextBlock elements in MainPage.xaml display the two chunks of title text in a new Silverlight program.

PhoneApplicationPage, Grid, StackPanel, and TextBlock are all Silverlight classes. In Markup these become XML elements. Properties of these classes become XML attributes.

The nesting of elements in MainPage.xaml is said to define a visual tree. In a Silverlight program for Windows Phone 7, the visual tree always begins with an object of type PhoneApplicationFrame, which occupies the entire visual surface of the phone. A Silverlight program for Windows Phone 7 always has one and only one instance of PhoneApplicationFrame, referred to informally as the frame.

In contrast, a program can have multiple instances of PhoneApplicationPage, referred to informally as a page. At any one time, the frame hosts one page, but lets you navigate to the other pages. By default, the page does not occupy the full display surface of the frame because it makes room for the system tray (also known as the status bar) at the top of the phone.

Our simple application has only one page, appropriately called MainPage. This MainPage contains a Grid, which contains a StackPanel with a couple TextBlockGrid, all in a hierarchical tree. The visual tree of a Silverlight program creates by Visual Studio is: elements, and another

Grid named "LayoutRoot"
StackPanel named "TitlePanel"
TextBlock named "ApplicationTitle"
TextBlock named "PageTitle"
Grid named "ContentPanel"

Our original goal was to create a Silverlight program that displays some text in the center of the display, but given the presence of a couple titles, let’s amend that goal to displaying the text in the center of the page apart from the titles. The area of the page for program content is the Grid towards the bottom of the file preceded by the comment “ContentPanel - place additional content here.” This Grid has a name of “ContentPanel” and I’m going to refer to it informally as the “content panel” or “content grid”. The area of the screen corresponding to this Grid apart from the titles I’ll often refer to as the “content area”.

In the content grid, you can insert a new TextBlock:

Example 5. Silverlight Project: SilverlightHelloPhone File: MainPage.xaml (excerpt)
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
<TextBlock Text="Hello, Windows Phone 7!"
VerticalAlignment="Center" />

Text, HorizontalAlignment, and VerticalAlignment are all properties of the TextBlock class. The Text property is of type string. The HorizontalAlignment and VerticalAlignment properties are of numeration types HorizontalAlignment and VerticalAlignment, respectively. When you reference an enumeration type in XAML, you only need the member name.

While you’re editing MainPage.xaml you might also want to fix the other TextBlock elements so that they aren’t so generic. Change

<TextBlock . . . Text="MY APPLICATION" . . . />


<TextBlock . . . Text="SILVERLIGHT HELLO PHONE" . . . />


<TextBlock . . . Text="page title" . . . />


<TextBlock . . . Text="main page" . . . />

It doesn’t make much sense to have a page title in a Silverlight application with only a single page, and you can delete that second TextBlock if you’d like. The changes you make to this XAML file will be reflected in the design view. You can now compile and run this program:

This screen shot—and most of the remaining screen shots in this book—are shown on the pages of this book with a size that approximates the size of the actual phone, surrounded by some simple “chrome” that symbolizes either the actual phone or the phone emulator.

As simple as it is, this program demonstrates some essential concepts of Silverlight programming, including dynamic layout. The XAML file defines a layout of elements in a visual tree. These elements are capable of arranging themselves dynamically. The HorizontalAlignment and VerticalAlignment properties can put an element in the center of another element, or (as you might suppose) along one of the edges or in one of the corners. TextBlock is one of a number of possible elements you can use in a Silverlight program; others include bitmap images, movies, and familiar controls like buttons, sliders, and list boxes.
Other -----------------
- Programming Windows Phone 7 : A First Silverlight Phone Program
- Programming Windows Phone 7 : Sensors and Services
- Programming Windows Phone 7 : The Hardware Chassis
- Windows Phone 7 : Deleting Music or Video
- Windows Phone 7 : Pinning Favorites to Start
- Windows Phone 7 : Listening to FM Radio
- Windows Phone 7 : Playing Podcasts
- Windows Phone 7 : Watching Videos
- Windows Phone 7 : Controlling Music Playback
- Windows Phone 7 : Playing Music
- Windows Phone 7 : Pinning a Favorite Place to Start
- Windows Phone 7 : Adding a Pushpin
- Windows Phone 7 : Changing Map Views
- Windows Phone 7 : Sharing an Address with Someone
- Windows Phone 7 : Getting Real-Time Traffic Conditions
- Windows Phone 7 : Getting Directions
- Windows Phone 7 : Seeing What’s Nearby
- Windows Phone 7 : Finding Places and Things
- Windows Phone 7 : Finding Yourself
- Windows Phone 7 : Working with Maps
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us