Vasu Balakrishnan’s Blog

Archive for the ‘WPF’ Category

ItemsControl

leave a comment »

I’ve started to use ItemsControl without much insight / understanding as to how it works. I came across this blog, and what a great resource. There is a very good series of posts about ItemsControl A to Z. I would definitely recommend this.

Advertisements

Written by nbvasu

August 6, 2009 at 2:42 pm

Posted in WPF

WPF Trees

leave a comment »

WPF has the notion of Logical / Visual trees. The logical trees represents the control hierarchy as defined by the developer either via XAML or code. Just about every aspect of WPF (Properties, Events, Resources, etc) has behavior tied to the logical tree. Visual tree is an expansion of logical tree, in which nodes are broken down into their core visual components. The visual tree describes the structure of visuals (elements that inherit of Visual base class). Content elements (deriving from ContentElement) are not part of the Visual tree. Routed events travel along the visual tree and not the logical tree. Visual tree is of interest if you want low level control over drawing for performance / optimization. 

You should avoid writing code against the Visual tree as it breaks once of core principle of WPF – separation of look and logic. A Visual tree can change simply by a user switching to a different Windows theme. Visual tree is empty until the window undergoes layout at least once.

You can traverse Logical / Visual tree using LogicalTreeHelper / VisualTreeHelper classes.

Here is an article that goes further in explaining the trees.

Written by nbvasu

June 30, 2009 at 4:17 pm

Posted in WPF

XAML

leave a comment »

As I’m reading XAML Demystified chapter from book, few things caught my attention and I didn’t know about them before.

  • “XAML is a relatively simple and general purpose declarative programming language suitable for constructing and initializing .NET objects”. I’d thought XAML was built for WPF. The author say that it could be applied to any .NET technology like Workflow Foundation, etc. I then did a quick search for XAML usage and it led me to video where they talk about XAML in .NET 4.0. I’m excited about some of the upcoming features.
  • XAML specification defines rules that map .NET namespaces, types, properties, and events into XML namespaces, elements and attributes. XAML was designed to work with .NET type system, and can be used with just about any .NET object.
  • At runtime, event handlers are always attached before any properties are set declared in XAML (excluding Name property which is set immediately after object construction)
  • Property Elements – They always take form as TypeName.PropertyName, they are always contained within the TypeName object element and can never have attributes of their down. They can be used for simple properties as well.
  • Type Converters – They know how to convert the string representation to the desired data type.
  • Markup Extensions, like Type Converters, enable you to extend the expressibility of XAML. Both can evaluate string value at run-time and produce an appropriate object based on the string. Unlike Type Converters, Markup Extensions are invoked from XAML with explicit and consistent syntax. They support Positional / Named Parameters. Positional parameters are treated as string parameters to the extension class’s appropriate constructor.
  • An Object element can have three types of children – a value for content property, collection items or a value that can be type converted to its parent. To avoid ambiguity, the following rules are followed by XAML compiler when encountering / interpreting child elements

    • If type implements IList, call IList.Add for each child
    • If type implements IDictionary, call IDictionary.Add for each child, using Key attribute value for key and element for the value
    • If the parent supports Content property and the type of the child is compatible with that property, treat the child value as its value
    • If the child is plain text, and a type converter exists to transform the object into the parent type, treat the child as input into the converter and the use output as the parent object instance.
    • If none of the above applies, raise an error.
  • WPF’s runtime XAML parser is exposed as two class XamlReader / XamlWriter.
  • XAML language namespace has a Name keyword that enables you to give any element a name. x:Name syntax is used to name elements but that can be overridden to any other property using a custom attribute RuntimeNameProperty. You can use either mechanism but not both.
  • XAML compilation involves three things: converting a XAML file into a special binary format, embedding the converted content as a binary resource (BAML) in the assembly being built and performing the plumbing that connects XAML with procedural code automatically.  BAML stands for Binary Application Markup Language, is simply XAML that has been parsed, tokenized and converted into binary form. Its a compressed declarative format that is faster to load and parse. Its just an implementation detail of the XAML compilation process. This does not generate procedural source code. Some procedural code do get generated (if you use x:class) but its just some glue code written to load / parse a loose XAML file at runtime. They files are given .g.cs suffix. The glue code generates a partial class (specified by x:class), contains a field (private by default) for every named element in the XAML. It also has an InitializeComponent method that does the work of loading embedded BAML resource, assigning fields to appropriate instances originally declared in XAML and hooking up event handlers. BAML can be decompiled back to XAML using Application.LoadComponent.

The last item in the list, is something that I wasn’t aware of. I’ve seen the glue code few times as part of my debugging process, but didn’t pay attention to it. Now it makes it clear.

I’m moving on to next chapter…

Written by nbvasu

June 29, 2009 at 2:10 pm

Posted in WPF

WPF

leave a comment »

I’m currently reading Windows Presentation Foundation Unleashed book by Adam Nathan. I’ve just finished the introductory part. I just skimmed over Chapter 2 (XAML Demystified) and I’m going to read it again. The author has done a good job in going into the internals of XAML, even MSDN reference didn’t mention them in the documentation. So far I like this book. I’ll post my reviews / thoughts on the book in my following posts.

Written by nbvasu

June 29, 2009 at 10:36 am

Posted in WPF

WPF Dependency Properties

with one comment

One of the fundamental feature of the WPF framework is the Dependency Properties (DP). When I started to work with WPF, I didn’t fully understand how it all worked. Then as I start to read more about it, I began to understand and appreciate its role. Here I am trying to put together in a nutshell, what I learnt about DP.

  • MSDN Definition – Any property that is backed by WPF property system is a DP. OK thats a vague definition.
  • These are used when the resolution of a property value is based on other properties / runtime settings. Thats the key right here.
  • The resolution process has an order of precedence it assigns to various environmental contexts
  • The rules of precedence are
  1. Property System Coercion
  2. Animations
  3. Local Value
  4. TemplatedParent Template
  5. Style Triggers
  6. Template Triggers
  7. Style Setters
  8. Theme Style
  9. Inheritance
  10. Default Value from DP Metadata
  • DP supports self contained validation – has custom callback methods execute when the value has changed. These can validate the new value or coerce the value into something acceptable
  • Support for Default Values – Has a consistent mechanism to associate default value with the property and has the lowest precedence in the value resolution process
  • Property Metadata – This determines the DP behavior. It is supplied when the property is registered with the system.
  • Value Inheritance – DPs have the ability to inherit its value from the property setting on the ancestor element in the logical tree
  • DPs are the foundation blocks for the data binding in WPF. The DataContext property in FrameworkElement is a defined as a DP. This means all the descendant elements in the logical tree share the same data source.
  • DPs are registered via a static method. You can retrieve value using GetValue and set value using SetValue method
  • To use DP, you’ve to inherit from DependencyObject

AttachedProperty (AP) – This is a special form of Dependency property that is worth mentioning here.

  • One of the purpose of AP, is to let different child elements specify values for property that is defined in a parent element.
  • This works like javascript’s expando properties
  • One example is the DockPanel.Dock property. This is created as an attached property because it is designed to be set on elements that are contained within the DockPanel
  • AP lets child elements inform parent elements how they are to be presented in the UI
  • They are XAML concept, whereas DP as WPF Concept.

Source:

DP – http://msdn.microsoft.com/en-us/library/ms752914.aspx
       http://joshsmithonwpf.wordpress.com/2007/06/22/overview-of-dependency-properties-in-wpf/

AP – http://msdn.microsoft.com/en-us/library/ms749011.aspx

Written by nbvasu

May 12, 2009 at 9:43 pm

Posted in General, WPF

Tagged with