Let's take a look at WPF from 10,000 foot view:
Direct X - used to render the actual pixels onto the screen.
Composition Engine - (Media Integration Layer) - It's a native component written in unmanaged code that resides in milcore.dll and is responsible for providing support 2D and 3D imaging. It interfaces directly with Direct X. It's written in unmanaged code for a simple reason: Direct X uses COM Interfaces to communicate with the outside world and these calls do not come very cheap in the managed world of interop calls.
Presentation Core - exposes rendering services of the Composition Engine - essentially managed wrapper for the Composition Engine.
Presentation Framework - provides concepts such as: Control, Layout, command handling, data binding, etc.
XAML or Extensible application markup language.
I've said it again, and I'll say it again: WPF doesn't need XML and XML doesn't need WPF. It's simply a language for building .NET objects and XAML user interfaces are built as trees of objects.
Let's take a look at a simple button:
1: <Page
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
4: <Grid HorizontalAlignment="Center" VerticalAlignment="Center">
5: <Button x:Name="XAMLButtonTest"
6: FontFamily="Veranda"
7: FontSize="42"
8: Foreground="DarkRed">
9: _Submit!
10: </Button>
11: </Grid>
12: </Page>
Note: On Line 4 HorizontalAlignment="Center" VerticalAlignment="Center" properties describe how a child elements should be position within its parent. i.e. this is what actually makes a button, otherwise it would fill out all available space.
Also, note that I have prefixed the '_Submit' - this is how you define Mnemonic in WPF. (you need to hold an ALT key in order for it to show up)
XAML is a language for building .NET objects and here is how we would accomplish the same thing in C# using object initializer:
var xmlButtonTest = new Button
{
FontFamily = new FontFamily("Veranada"),
FontSize = 42,
Foreground = Brushes.DarkRed,
Content = "_Submit"
};
There are two concepts how the input is handled in WPF, these are routed events and routed commands.
Events routing allows events to be handled by ancestor of the element who originated the event - there are two patterns for doing that:
1. Bubbling (most common)
The event propagates up the visual tree from the source element.
2. Tunneling
These, as you may suspect, go the other way, down from the source element.
Events come in pairs: There's usually a preview event that tunnels, followed by an event that bubbles - the reason being is so that the main element gets the first opportunity to respond or react to that event.
Controls
WPF controls have no intrinsic look, they are 'lookless' - this is because templates can replace default look with your own design, unlike in WIN32 where we do have a default look.
Let's take a look at how to define a template for a button, i.e. custom look, using property element syntax:
Line 2: The part before the dot is interpreted as the 'class name' and the part after the dot as the 'property name'.
Line 3: TargetType="Button" - defines what control is the template for.
1: <Button Width="64" Height="30">
2: <Button.Template>
3: <ControlTemplate TargetType="Button">
4: </ControlTemplate>
5: </Button.Template>
6: </Button>
The code above represents the natural look for the button which essentially is 'no look'.
Let's fill in the appearance: (fully working XAML)
1: <Window x:Class="WpfApplication2.MainWindow"
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4: Title="MainWindow" Height="350" Width="525">
5: <Grid HorizontalAlignment="Center" VerticalAlignment="Center">
6: <Button Width="85" Height="45" Background="SteelBlue" VerticalAlignment="Center" HorizontalAlignment="Center">
7: <Button.Template>
8: <ControlTemplate TargetType="Button">
9: <Grid>
10: <Rectangle Fill="{TemplateBinding Background}" RadiusX="8" RadiusY="8"></Rectangle>
11: <ContentPresenter RecognizesAccessKey="True"
12: Content="{TemplateBinding Content}"
13: VerticalAlignment="{TemplateBinding VerticalAlignment}"
14: HorizontalAlignment="{TemplateBinding HorizontalAlignment}" />
15: </Grid>
16: </ControlTemplate>
17: </Button.Template>
18: _Submit
19: </Button>
20: </Grid>
21: </Window>
Line: 10 "TemplateBinding Background" - allows us to bind the property 'Background' on line: 6 to the Content Presenter which essentially is a placeholder for any XAML content to be used during runtime.
The curly brackets tell XAML that we are using something called: the markup extension. (more about it in future posts). For now, let's just say that markup extensions decide during runtime how the properties are set. What line 10 says is that we are creating an object of type: TemplateBinding and we are passing a string (yes, string) called 'Background' to a constructor.
Primitive elements:
The elements that define or rather have template are the controls in WPF, and as you may suspect not everything is a control in WPF. In other words you don't have to worry as to how anything ever appears on your screen when programming in WPF. It's only the elements that derive from the Control class, such as button that look for their appearance in template.
For example Rectangle, TextBlock and Image derive from the framework element - these are primitives and do not have a template of their own.
Layout primitives:
Grid Panel - flexible grid-based area with columns and rows.
Canvas Panel - fixed area to position elements by the use of coordinates.
Stack Panel - simple vertical or horizontal arrangement in a single line.
Dock Panel - allows to arrange child elements vertically or horizontally relative to each other; similar to windows forms docking.
Wrap Panel - allows to arrange child elements in a flow-like formatting.
No comments:
Post a Comment