playground

In the previous post  we have seen that, elements in the WPF object tree which derive from Visual constitute the visual tree. The visual tree is thus all the WPF elements that come together to render a control’s (or a set of controls’) UI to the screen. Control templates are XAML declarations of the visual tree of a control. Consider the simple case of a Button control, <!-- A default button --> <Button Height="100" Width="100" Content="Click Me!" /> </Grid> The Button has a default visual template, i.e, a visual tree supplied by WPF. We want to override this implementation and provide our own custom UI for the button. To do this we’ll customize the Button control’s UI template (and thus it’s visual tree). This is simple enough, <Grid> <!-- A default button --> <Button Height="100" Width="100" Content="Click Me!"> <!-- Override the Button...

To be clear at the outset, there is only one object tree in WPF, which is created based on the nested relationships of the elements in the markup (the markup may be built via XAML or code). The logical and visual trees are two different ways of looking at this object tree. They are both subsets of the object tree. When we’re creating some UI in XAML, for example, <!-- Note: no x:Class, load this XAML using XmlReader.Create --> <Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="300" Height="300"> <Grid> <Button Height="100" Width="100" Content="Text" /> </Grid> </Window> You may intuitively think of a tree structure that looks like the one below (arrows point to parent). In reality, the object tree is far more complex and has many more elements. This simplified subset of the ...

In .Net 1.1/2.0, a typical CLR property looks like this, // Private field private int _postId; // Public property that wraps the private field public int PostId{ get { return _postId; } set { _postId= value; } } For a regular CLR property, the property value is read directly from a private class member. WPF introduces a new construct called a dependency property, which can get its value from different sources and the actual value resolution occurs dynamically at run-time based on some precedence rules. For example, a TextBox‘s Text property, which is a dependency property, can get its value from a style, a trigger, an animation, or locally (among others). Consider the following XAML, <Grid.Resources> <Style x:Key="TextBoxBaseStyle" TargetType="TextBox"> <Style.Triggers> <Trigger Property="IsMouseOver" Value="True"> <Setter Property="Text" Value="T...

In previous article , we learned Styles, Triggers are similar to styles, the difference is Styles are applied to controls unconditionally whereas Triggers as based on one or more conditions. There are four types of Triggers, Property triggers are invoked when a dependency property changes.  Event triggers are invoked when a routed event is raised.  Data triggers are invoked when a regular .NET property changes.  Multi triggers (and MultiData triggers) represent a logical AND relationship between triggers. 1. Property triggers : A property trigger executes a collection of Setters when a specific dependency property changes to a specific value. When the dependency property no longer has the specified value, the Setters are undone with no additional code required. For example, if we want to change the background of a TextBox, when it is moused-over we can simply do this, <Grid> <Grid.Resources> <!-- Define a named style... --> ...

A style in WPF is the collection of (dependency) properties that affect the appearance and behavior of a control. For example, the text color inside a TextBox and background of a Button. For our examples, say we’re trying to affect the styles of two textBoxes, <Grid x:Name="MyGrid"> <Grid.ColumnDefinitions> <ColumnDefinition /> <ColumnDefinition /> </Grid.ColumnDefinitions> <TextBox Grid.Column="0" /> <TextBox Grid.Column="1" /> </Grid> Since the textBoxes don’t have a height and width, lets use a named style to set them. <Grid.Resources> <Style x:Key="TextBoxBaseStyle"> <!—- Named style (because we defined an x:Key) -–> <!—- Property=”[ClassName].[DependencyProperty]” -–> <Setter Property="Control.Height" Value="30" /> <Setter Property="Control.Width" ...

This pattern is best illustrated in code as the source describes it a lot more concisely than in prose. One central class (the mediator) is used by many ‘client’ classes to send messages with (n.b. ‘client’ is my own term not one from the original pattern description). A ‘client’ or several ‘client’ classes then have a reference to this mediator instance as a private field, and use it to send messages. The mediator has an event which each ‘client’ subscribes to. This event is fired each time the mediator sends a message. Example A chat room could use the Mediator pattern, or a system where many ‘clients’ each receive a message each time one of the other clients performs an action (for chat rooms, this would be when each person sends a message). In reality using the Mediator pattern for a chat room would only be practical when used with remoting. Using raw sockets wouldn’t allow for the delegate callbacks (people subscribed to the Mediator class’ MessageReceived event).   ...