SayHello

using System; using System.Windows; namespace Liyang.SayHello { class SayHello { [STAThread] public static void Main() { windows win = new window(); win.Title = "Hello Dabby"; win.Show(); Application app = new Application(); app.Run(); } } }

 

An application written for the Microsoft Windows Presentation Foundation (WPF) generally begins its seconds or hours on the Windows desktop by creating objects of type Application and Window. A simple WPF program looks like this:

SayHello.cs
//----------------------------------------- // SayHello.cs (c) 2006 by Charles Petzold //----------------------------------------- using System; using System.Windows; namespace Petzold.SayHello { class SayHello { [STAThread] public static void Main() { Window win = new Window(); win.Title = "Say Hello"; win.Show(); Application app = new Application(); app.Run(); } } }

 

You're familiar with the System namespace, I assume. (If not, you should probably read my online book .NET Book Zero available on my Web site at www.charlespetzold.com.) The SayHello program also includes a using directive for System.Windows, which is the namespace that includes all the basic WPF classes, structures, interfaces, delegates, and enumerations, including the classes Application and Window. Other WPF namespaces begin with the preface System.Windows, such as System.Windows.Controls, System.Windows.Input, and System.Windows.Media. A notable exception is the namespace System.Windows.Forms, which is the primary Windows Forms namespace. All namespaces that begin with System.Windows.Forms are also Windows Forms namespaces, except for System.Windows.Forms.Integration, which includes classes that can help you integrate Windows Forms and WPF code.

The sample programs shown in this book have a consistent naming scheme. Each program is associated with a Microsoft Visual Studio project. All code in the project is enclosed in a namespace definition. The namespace always consists of my last name followed by the name of the project. For this first example, the project name is SayHello and the namespace is then Petzold.SayHello. Each class in the project is given a separate source code file, and the name of the file generally matches the name of the class. If the project consists of only one class, which is the case for this first example, that class is usually given the same name as the project.

In any WPF program, the [STAThread] attribute must precede Main or the C# compiler will complain. This attribute directs the threading model of the initial application thread to be a single-threaded apartment, which is required for interoperability with the Component Object Model (COM). "Single-threaded apartment" is an old COM-era, pre-.NET programming term, but for our purposes you could imagine it to mean our application won't be using multiple threads originating from the runtime environment.

In the SayHello program, Main begins by creating an object of type Window, which is the class you use for creating a standard application window. The Title property indicates the text that will appear in the window's caption bar, and the Show method displays the window on the screen.

The final important step is to call the Run method of a new Application object. In Windows programming parlance, this method creates the message loop that allows the application to receive user input from the keyboard and mouse. If the program is running on a Tablet PC, the application also receives input from the stylus.

You'll probably use Visual Studio 2005 to create, compile, and run applications written for the Windows Presentation Foundation. If so, you can re-create the SayHello program by following these steps:

1.	Select New Project from the File menu.
2.	In the New Project dialog, select Visual C#, Windows Presentation Foundation, and Empty Project. Find a good home for the project and give it the name SayHello. Uncheck the Create Directory For Solution option. Click OK.
3.	In the Solution Explorer on the right, the References section must include PresentationCore, PresentationFramework, System, and WindowsBase. If the References section doesn't include these DLLs, add them. Right-click References and select Add Reference. (Or, select Add Reference from the Project menu.) In the Add Reference dialog, click the .NET tab and select the required DLLs. Click OK.
4.	In the Solution Explorer on the right, right-click the SayHello project name and then select New Item from the Add menu. (Or, select Add New Item from the Project menu.) In the Add New Item dialog, select Code File. Type in the file name SayHello.cs. Click OK.
5.	Type the program shown earlier in the chapter into the SayHello.cs file.
6.	Select Start Without Debugging from the Debug menu (or press Ctrl+F5) to compile and run the program.

For most of the example programs shown in Part I of this book, the process of creating projects will follow basically the same steps, except that some projects (including one in this chapter) have multiple source code files.

When you close the window created by SayHello, you'll discover that a console window has also been running. The presence of this console window is governed entirely by a compiler flag that you can control in the project's properties. Right-click the project name at the right and select Properties from the menu. (Or, select Properties from the Project menu.) Now you can explore or alter aspects of the project. Note that the Output Type is set to Console Application. Obviously this setting hasn't affected the program's ability to go far beyond the console in creating a window. Change the Output Type to Windows Application, and the program will run as before but without the console window. I personally find the console window very useful in program development. I use it for displaying textual information while the program is running, and for debugging. If a program is so buggy that it doesn't even display a window, or if it displays a window but enters an infinite loop, it's easy to terminate the application by typing Ctrl+C in the console window.

The Window and Application classes used in SayHello both derive from DispatcherObject, but Window has a much longer pedigree, as shown in the class hierarchy:

Object

DispatcherObject (abstract)

Application

DependencyObject

Visual (abstract)

UIElement

FrameworkElement

Control

ContentControl

Window

Of course, it's not necessary to be intimately familiar with the class hierarchy just yet, but as you make your way through the Windows Presentation Foundation, you'll encounter these classes again and again.

A program can create only one Application object, which exists as a constant anchor for the rest of the program. The Application object is invisible; the Window object is notit appears on the screen in all its glory as a standard Windows window. It has a caption bar displaying the text indicated in the Title property. The caption bar has a system menu icon on the left, and minimize, maximize, and close icons on the right. The window has a sizing border, and it has a client area occupying the vast interior of the window.

Within limits, you can mix up the order of the statements in the Main method of the SayHello program and the program will still work. For example, you can set the Title property after calling Show. In theory, that change causes the window to be displayed initially without a title in its caption bar, but the change will probably happen too quickly to see.

You can create the Application object before creating the Window object, but the call to Run must be last. The Run method does not return until the window is closed. At that point, the Main method ends and Windows cleans up after your program. If you remove the call to Run, the Window object is still created and displayed, but it's immediately destroyed when Main ends.

Instead of calling the Show method of the Window object, you can pass the Window object as an argument to the Run method:

app.Run(win);

 

In this case, the Run method takes the responsibility of calling Show for the Window object.

A program doesn't really get started until it calls the Run method. Only then can the Window object respond to user input. When the user closes the window and the Run method returns, the program is ready to terminate. Thus, the program spends almost all of its existence deep within the Run call. But how can the program do anything if it is spending all its time in Run?

Following initialization, virtually everything a program does is in response to an event. These events usually indicate keyboard, mouse, or stylus input from the user. The UIElement class (which refers to the user interface, of course) defines a number of keyboard-, mouse-, and stylus-related events; the Window class inherits all those events. One of those events is named MouseDown. A window's MouseDown event occurs whenever the user clicks the client area of the window with the mouse.