Page 2 of 4
There are lots of reasons why WPF is a second generation GUI and one of the most important is that it makes use of the modern video hardware nearly all machines have.
The Windows Forms API was invented in the days when graphics cards were simple and it makes very little use of hardware graphics acceleration. WPF, on the other hand, uses the DirectX rendering engine and this does make use of graphics acceleration. It also means that WPF has access to a wide range of visual effects for full 3D presentation, including meshes, materials, lights, textures and so on.
Yes, WPF provides you with yet another way of creating 3D graphics under Windows. Unfortunately this often doesn't go far enough for many uses.
At a more mundane level all of the elements of any UI you create using WPF are rendered using vector graphics, rather than bitmaps, and this means that they display at the highest resolution the display device supports. It is also a “retained” mode graphics system which makes anything you draw on a form persistent without you having to redraw it. For example, if you draw a line on a form and the form is minimised the line is still there when the form is restored and you don’t have to redraw it. Retained mode allows the graphics system to optimise the display process.
WPF also implements a better and more sophisticated event system. It also supports UI features that make it easier to implement advanced architecture like MVC. In particular WPF supports data binding which will automatically display and update data bound to UI controls.
The most obvious feature of WPF is XAML and it is worth pointing out that even though XAML is central to the way most people use WPF you can have WPF without XAML. Given XAML has gone off and got a life of its own it is also true that you can have XAML without WPF.
WPF without XAML
It is a much over looked fact that if you don’t want to use XAML then you don’t have to.
There are still .NET classes for each and every WPF component that you care to use.
For example as well as there being a <Button> tag there is a Button class within the framework (not to be confused with the Windows Forms Button class).
In fact there has to be a framework class for everything in XAML because XAML is just an object creator and initialisation language. XAML is always converted to framework objects, properties and methods. What this means is that, if we want to, we can create the same objects and work with their properties and methods without any XAML.
If you want to code our first example using minimal XAML you can first delete the grid tags and everything between them and then enter the following code in the code page within the MainWindow class definition:
public partial class MainWindow : Window
public Button Button1;
Grid g = new Grid();
Button1 = new Button();
Button1.Height = 50;
Button1.Width = 200;
Button1.Content = "Click Me";
Button1.Click += OnClick1;
this.Content = g;
void OnClick1(object sender,
Button1.Content = "Hello World";
It looks more complicated and it’s longer but you should be able to see that it does the same job as the XAML by creating objects and setting their properties.
So use XAML or don’t use XAML, the end result is the same. In the rest of this article the focus will be on using XAML but converting any of the examples into pure code is relatively easy. It is also useful to know how to work with the UI in code as well as within the markup.
You should now be starting to see the basic principles of WPF, but where next?
There are lots of features that you could explore but before we look at something more exciting it is worth looking a little closer at the way a user interface is put together.
The approach taken by WPF would be familiar to anyone using Java or a number of other similar languages but to the Windows forms programmer it is a little strange.
Of course WPF has all of the user interface controls you would expect – buttons, textboxes, drop down lists - and many more advanced controls such as calendar and menu bar. However, at the top of it all is the Visual class from which any element that has a visual aspect is descended.
Every visual component has a Content property, which roughly corresponds to what will be displayed.
For example, a Window object has a Content property, which specifies what it displays. In some cases all you need to do is set a Content property to an appropriate value. For example,
Button1.Content= “Click Me”
sets the text the button displays. In all cases the Content property can be set to text or a UIElement such as an Image object.
Notice that at the moment the content of any visual component is restricted to be just one other component.
In most cases we have to work with a Content consisting of multiple objects. This means we have to worry about how these are arranged, i.e. we have to worry about layout.
Layout is dealt with by the Panel objects.
Usually we assign a Panel object to the content of a Window and then assign other display objects to the Panel object’s layout hierarchy. Exactly how these objects are arranged depends on the type of Panel object we use.
Currently there are five standard layout Panels: Canvas which provides absolute x,y positioning; DockPanel which allows the user to interactively “dock” elements; Grid which provides fixed columns and rows for positioning; StackPanel which arranges objects into a horizontal or vertical line; and WrapPanel which arranges objects as a “flow” in the same way that a web page works.
You can see that the Canvas Panel provides the absolute layout that we are accustomed to working with in Windows forms. The WrapPanel is probably the one least like a traditional form.
To see this in action simply enter the following XAML (replace the <Grid></Grid> tags):
Now if you run the project and resize the form you will see that the three buttons move to use the available space – just like the text in a web page.
It is also worth realising that this particular object hierarchy has been implement in a rigid and logical way – sometimes with surprising consequences.
If you recall, a Content property can be set to any UIElement and this means that you can display a button within a button:
<Button Height="50" Width="200" >
<Button Height="20" Width="100" >
If this isn’t mind-boggling enough, you can logically set the content of a button to a Panel and then display lots of other controls within the button.
<Button Height="200" Width="200" >
<Button Height="20" Width="100" >
<Button Height="20" Width="50" >
<Button Height="20" Width="40" >
<Button Height="20" Width="100" >
Buttons within buttons...
Yes the outer button and any of the inner buttons can still be clicked!
Perhaps this is user interface madness but it is logical and in other contexts even useful. The point isn't to get you to start nesting one control within another but to make clear the logic of how WPF organizes its control classes.