Vasu Balakrishnan’s Blog

Worth a read

leave a comment »

The Little Book of Semaphores via Simon Brunning

Advertisements

Written by nbvasu

August 18, 2009 at 10:19 am

Posted in General

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.

Written by nbvasu

August 6, 2009 at 2:42 pm

Posted in WPF

C# Explicit Interface Implementation

leave a comment »

 

C# lets you explicitly implement an interface. When you do that the interface member can be accessed only by using a reference to the interface. I was wondering why do we need this feature.

It turns out when you’ve a class that implements multiple interfaces,  which have some common methods in them and they don’t perform the same function. You can then implement the interface explicitly. Here is an example from MSDN

interface IControl
{
    void Paint();
}
interface ISurface
{
    void Paint();
}

// Implicit Implementation
class SampleClass : IControl, ISurface
{
    // Both ISurface.Paint and IControl.Paint call this method.
    public void Paint()
    {
    }
}

// Explicit Implementation
public class SampleClass : IControl, ISurface
{
    void IControl.Paint()
    {
        System.Console.WriteLine("IControl.Paint");
    }
    void ISurface.Paint()
    {
        System.Console.WriteLine("ISurface.Paint");
    }
}

 

Also explicit interfaces can be used to resolve cases when two interfaces each declare different members of the same name (like a property and a method).

One of the most common reason to explicitly implement an interface, is to hide them from developers as they don’t appear in the publicly visible members.

Written by nbvasu

July 29, 2009 at 10:44 am

Posted in C#

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

F# |> operator

leave a comment »

 

As I was reading this blog, it made it clear to me the usefulness of currying, partial application forward pipe concepts of a functional program.

Look at the following lines of code in C#. If we don’t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

 
var list = new List<int> {4,2,6,5,9,3,8,1,3,0};
Console.WriteLine(Square(CalculateSum(FilterEven(list))));

 

The same can be written in F# as below. We describe the data flow in exactly the same order we talked about it.

 
let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0] 
let square x = x * x
list 
    |> List.filter (fun x -> x % 2 = 0) // partial application 
    |> List.sum 
    |> square 
    |> printfn "%A" // partial application

 

Written by nbvasu

June 18, 2009 at 10:59 pm

Posted in F#