I will tackle specific WPF concepts separately in future posts.
WPF is a powerful framework for building windows applications, however there is a steep curve in learning. The whole WPF framework only makes sense when all the individual pieces of the framework fall in together. In other words, one must understand the entire WPF framework in order to understand any of it.
1. How Windows Forms differ from WPF?
Windows forms are simply wrappers around USER 32 and GDI 32 APIs - which provide the traditional Windows look and feel and drawing support for rendering shapes, text, images, etc. respectively.
WPF doesn't use GDI 32 rendering API at all, it's part of .NET and a mixture of managed and unmanaged code and it's only available from .NET - i.e. no public, unmanaged API calls allowed.
2. What's in it for me?
Today's hardware and graphics cards in particular offer a lot of computing power, it's not unheard of having gigabytes of memory purely on the graphics cards. If fact today's graphics cards have more processing power than windows machines did 25 years ago, back when user.exe (16bit dll - and yes it had .exe extension) and later 32-bit backwards compatible USER 32 were designed. Also, remember that GDI and USER subsystems were introduced with Windows 1.0 in 1985.
The USER 32 and GDI 32 subsystems weren't designed for the new powerful graphics cards, so most of the power sits unused.
How do we take advantage of new graphics cards that offer 3D accelaration?
One way is to write open GL or Direct X code, but that of course does not easily intergrate with user interface application, drop down boxes, data binding, etc. Using (or so I've heard) Direct X API to create windows business applications isn't for the faint of heart. That's where WPF comes in. WPF uses Direct X API, so all WPF drawing is performed through Direct X, which allows it to take advantage of the latest in modern video cards.
There's also an issue with resolution, classic style of constructing user interfaces has issues on modern PCs because windows applications are bound by certain assumptions about screen resolution and that makes traditional applications unscalable. Windows applications render small on very high resolution monitors because they cram pixels more densely.
WPF does not have this problem, because it uses system DPI setting and renders all elements on the screen by itself, so a button that's 1 inch long on low resolution monitor will remain 1 inch long on a high resolution monitor. In other words, all elements on the screen are measured using device-independent units.
Of course it is possible to write an application (without using WPF) that scales up or down itself and adapts to different screen resolutions (pixel size of the display), however most displays or monitors in the past had roughly the same pixel size, so of course nobody bothered to do that. Luckily for us WPF applications are DPI aware and hence scalable by default, nothing special needs to be done on your part.
3. Let's get our hands dirty and do some XAML WPF test (without actually writing any real code)
Note: It may surprise you but WPF doesn't need XAML and XAML doesn't need WPF.
Althought most of WPF is written using XAML.
Back in the day Microsoft used to bundle XamlPad with Visual Studio 2008, but it has been discontinued. You can still get it if you have MSDN Subscription but since not everyone reading this has one I found an alternative solution: Kaxaml.
It essentially lets you enter XAML and see what it will look like.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Button Content="OK" Width="85" Height="25"/>
</Grid>
</Page>
Now, if you zoom in, you can see that the button does not get pixelated.
Composibility - it's the power of WPF. We can compose all the different styles of content that WPF supports inside the button, so let's take this basic button control and...
a. Add layout:
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Button Width="85" Height="25" >
<StackPanel>
<TextBlock Text="OK"/>
</StackPanel>
</Button>
</Grid>
</Page>
Button in WPF lets you add only one child, just so it doesn't have to be in charge of how all the other children are laid out, here I've used <StackPanel> so I can add more children later.
2. Format text:
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Button HorizontalAlignment="Center" VerticalAlignment="Center">
<StackPanel>
<TextBlock FontSize="30"> WPF <Italic>Rulez</Italic> </TextBlock>
</StackPanel>
</Button>
</Grid>
</Page>
Notice that I've added HorizontalAlignment and VerticalAlignment so that the button will size itself according to the content.
3. and some graphics:
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid>
<Button HorizontalAlignment="Center" VerticalAlignment="Center">
<StackPanel>
<TextBlock FontSize="30"> WPF <Italic>Rulez</Italic></TextBlock>
<Ellipse Fill="Red" Width="33.143" Height="33.143"/>
<Ellipse Fill="Blue" Width="33.143" Height="33.143"/>
</StackPanel>
</Button>
</Grid>
</Page>
Not very exciting graphics but the point to illustrate was composability of WPF.
As I've mentioned at the beginning, WPF does not necessarily need XAML, so how would
something like this?
<Button x:name="submitButton" FontSize="30" FontFamily="Arial'>_Submit</Button>be written without XAML? Here's how:
Button button = new Button();button.FontSize=30;button.FontFamily=new FontFamily("Arial");button.Content = "_Submit";That's it for the first.
