Page 1 of 4
WPF was Microsoft's killer UI construction kit - a second generation GUI. Then it looked as if it was on the way out but with Windows Forms in maintenance mode and a new interest in WPF it is still a good choice for your desktop projects.
This article is a short introduction to WPF - not only using it but a little of how it works and the philosophy behind it.
To follow the examples you will need a copy of Visual Studio - Community edition will do and the examples will be in C#. The ideas however apply to any .NET language and converting the examples to Visual Basic say is trivial - as most of the code is build up of method calls and XAML.You also need to have the latest .NET Framework installed.
If you start a new project you will see that as well as Windows Forms Application - which is the original way of creating a forms based application - you also have a choice of a number of WPF application types.
Notice that these differences are not just cosmetic.
A Windows forms application implements the application using the way Windows worked originally - with one message loop per window. A WPF application brings a completely new event handling technology with it that does away with multiple message loops and uses a message routing system instead.
In short WPF applications do things differently - they don't just look different.
Getting started - the basics of XAML
If you open a new Windows Application (WPF) project you will discover many of the immediately obvious differences between WPF and Windows Forms.
The most obvious is that now there is a new file type called by default Window1.xaml. XAML, eXtensible Application Markup Language – pronounced “zamel”, is a markup language introduced to allow user interfaces to be defined without the need to program.
You can think of it as HTML on steroids but there is also much more to say about it. XAML probably represents the single biggest innovation in WPF so much so that it is used in non-WPF project types such as WinRT apps.
As well as the .xaml file, the system also generates an associated .cs code file with the same name, i.e. Window1.xaml.cs by default. This is where you write the code that manipulates the user interface components specified in the XAML file.
If you have ever worked with ASP .NET this will sound very familiar – it is HTML with “code behind”. You can view the shift to WPF and XAML as away of making web and desktop programming similar. Some might say that the split into code and HTML is what makes web programming difficult and introducing the same split to desktop programming simply make everything worse.
If you run the generated project it should compile successfully and display a blank form. To make it a little more interesting let’s add a button and make it do something.
The principles behind what is going on will be explained in a moment but you should be struck by how similar it all is to using HTML to create a web page.
You can build a WPF form using the interactive designer - just drop a button on the form and customise it using the properties box. But unlike Windows Forms applications the interactive designer creates a XAML tag which specifies the button and all its properties.
Let's take a closer look at XAML and work with it directly for a moment.
If you select the Window1.xaml file you will see a designer window and below it the XAML that generates the form. In a Windows forms application the designer generated code in what ever language you were using - C#, VB or whatever - to create the buttons and other controls on the form. In the case of a WPF application the designer generates XAML. The XAML specifies the objects and their properties that make up the user interface. When you run the program the XAML compiler converts the XAML into instances of objects using the .NET Framework.
That is if there is a XAML tag which specifies a button then when you compile and run the program the XAML compiler creates an instance of the button object and initialises all its properties correctly ready for your program to use.
It is in this sense that XAML is a language for object creation and initialisation.
Let's take a look at some XAML.
The designer and XAML tab
With the Window1.xaml file select, select the XAML tab and between the <Grid> and </Grid> tags add the following:
This is the XAML markup for a button called Button1, at the specified size and at a default location (the centre of the form). A click event handler is also defined as OnClick1 and the initial content i.e. the button’s label is set to “Click Me”.
As the designer renders any XAML you enter directly you will be able to see the button you have just defined in the pane above.
The button and the XAML
Now if you select the code page and enter:
void OnClick1(object sender,
Button1.Content = "Hello World";
Notice that the code “knows” the name of the button that you have defined using XAML and the connection is made automatically that this OnClick function is indeed the event handler you specified in the XAML.
When you first encounter this automatic connection between the XAML markup and the code it feels odd - as if there is more going on behind the scenes than you can see. Later you simply accept it and make use of it.
Now if you run the program you will see a button in the middle of the form inviting you to click it and when you do it will say “Hello World”.
Your first WPF application