2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads This blog is doing awesome!.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 4,300 times in 2010. That’s about 10 full 747s.

 

In 2010, there were 12 new posts, growing the total archive of this blog to 16 posts. There were 21 pictures uploaded, taking up a total of 2mb. That’s about 2 pictures per month.

The busiest day of the year was August 5th with 69 views. The most popular post that day was Creating a Custom XAML TypeConverter.

 

Where did they come from?

The top referring sites in 2010 were dotnet.dzone.com, dzone.com, google.co.in, google.com, and twitter.com.

Some visitors came searching, mostly for xaml typeconverter, typeconverter xaml, visual studio stl port debug, xaml type converter, and silverlight typeconverter.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Creating a Custom XAML TypeConverter February 2010

2

Visualizing STLPort data structures in Visual Studio Debugger November 2009
2 comments

3

XAML and TypeConverters January 2010
2 comments

4

Dependency Properties in Silverlight April 2010
3 comments

5

Code Snippets in Visual Studio 2010 June 2010

Leave a comment

Filed under Uncategorized

Xcode – How to bring back the splash screen at launch

When Xcode is started, I like the fact that a splash screen comes up with a list of recent projects (shown below). I somehow unchecked the “show at launch” box, and now Xcode starts up in headless mode.

Xcode Splash.png

I checked all the preferences for Xcode, but could not figure out a way to bring the Splash screen back. It turns out, its not very intuitive. In order to bring the splash screen back, I needed to edit the property list file for Xcode. Navigate to ~/Library/Preferences and double click the com.apple.Xcode.plist property file. The files opens up in Property List Editor as show below:

PropertyListEditor.png

Scroll down to the property XCShowSplashScreen, and check its value box. Save the plist file, relaunch Xcode, and the splash screen should now show up.

Just a handy tip that I thought I should share.

3 Comments

Filed under Tools

Code Snippets in Visual Studio 2010

Visual Studio allows developers to save snippets of code which can be inserted at a later time. This saves on retyping blocks of code that are used often. I also find it very useful when I have to show code during presentations. Instead of typing everything live, I find it far easier to simply add the code block by block using code snippets.

VS 2010 improves the snippet functionality, and makes it easier to create code snippets. There’s two types of snippets:

- Expansion snippets are inserted at the cursor
- SurroundsWith snippets wraps around selected code

 

Creating a Custom Snippet:
Let’s go ahead and create a try-catch-finally Expansion snippet:

- Insert a new XML file to the project and call it TryCatchFinally.snippet. Make sure the file name ends with .snippet

- Right-click on the editor window and select Insert Snippet->Snippet. This creates a basic XML snippet template as shown below:

<CodeSnippet Format="1.0.0" 
             xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <Title>title</Title>
    <Author>author</Author>
    <Shortcut>shortcut</Shortcut>
    <Description>description</Description>
    <SnippetTypes>
      <SnippetType>SurroundsWith</SnippetType>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>name</ID>
        <Default>value</Default>
      </Literal>
    </Declarations>
    <Code Language="XML">
      <![CDATA[<test>
      <name>$name$</name>
      $selected$ $end$</test>]]>
    </Code>
  </Snippet>
</CodeSnippet>

- As you can see, by default the template contains both snippet types. Since I am creating an Expansion snippet, let's go ahead and get rid of the <SnippetType>SurroundsWith</SnippetType> tag.

- Update the Title to "Try Catch Finally", Shortcut to "trycf" and Description to "Adds a try-catch-finally block".

- Literal tag enables us to define editable values that are inserted into the snippet. In the try-catch-finally snippet, we want to allow the user to change the type of the Exception being caught. The ID tag is the name of the editable value so change it to "ExceptionName". The Default tag specifies the default value for our editable field. I want to catch all exceptions, so change the Default tag's value to "Exception".

- Finally, the code section contains what will be added when the snippet is inserted. Change the language to "CSharp", and the body to the following:

    <Code Language="CSharp">
      <![CDATA[
try
{

}
catch($ExceptionName$)
{

}
finally
{

}
      ]]>
    </Code>

- The final version of the TryCatchFinally.snippet file is shown below. For more details about the XML schema, take a look at the MSDN code snippets Schema Reference

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippet Format="1.0.0" 
             xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <Header>
    <Title>Try Catch Finally</Title>
    <Author>umair</Author>
    <Shortcut>trycf</Shortcut>
    <Description>Adds a try-catch-finally block</Description>
    <SnippetTypes>
      <SnippetType>Expansion</SnippetType>
    </SnippetTypes>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>ExceptionName</ID>
        <Default>Exception</Default>
      </Literal>
    </Declarations>
    <Code Language="CSharp">
      <![CDATA[
try
{

}
catch($ExceptionName$)
{

}
finally
{

}
      ]]>
    </Code>
  </Snippet>
</CodeSnippet>

Loading the Snippet into Visual Studio:

There are two ways to insert the above snippet into Visual Studio.

The most straightforward way is to put the .snippet files in VS 2010's code snippets directory. The default location for it is C:\Users\<UserName>\Documents\Visual Studio 2010\Code Snippets\. This folder contains sub-directories based on the language of the snippet. For my example, the snippet goes under Visual C#. Once put here, VS 2010 automatically picks up the snippets without the need to restart.

 

The second option is to import the .snippet file into Visual Studio.

- Inside Visual studio, go to Tools->Code Snippets Manager (Ctrl+K,Ctrl+B). This brings up the Snippets Manager.

- Press Import button, and navigate to the location where the snippet was saved. Select the .snippet file.

- Press OK.

 

Using the Code Snippet:

Type the name of the snippet (the shortcut), and pressing tab expands it.

Intellisense after typing snippet name

You can also press Ctrl+K and Ctrl+X which brings up the "Insert Snippet" menu as shown below:

We can navigate to My Code Snippets, and select the TryCatchFinally that we've just added:

7 Comments

Filed under Visual Studio

XAML Resources

Every element in Silverlight contains a Resource property that maintains a dictionary of resources. This collection can hold any type, and a key is used to refer to each individual resource. Each element has access to its own resources as well as the resources in all its parents. For this reason, a common way to define resources is at the page level so that all elements within that page can re-use that resource. If a given resource will be used across the entire application (i.e. multiple pages), then it is put in the <Application.Resources> section of the App.xaml file.

To find a resource, Silverlight recursively searches up the element tree terminating at the <Application.Resources> section in App.xaml file.

As an example, suppose I re-use a custom brush on multiple elements on my page. I put it in the <UserControl.Resources> section where it can be accessed by all elements on my page. It is defined as:

    <UserControl.Resources>
        <LinearGradientBrush x:Key="CustomBrush">
            <GradientStop Offset="0.00" Color="Yellow" />
            <GradientStop Offset="1.00" Color="Orange" />
        </LinearGradientBrush>
    </UserControl.Resources>

Using a Resource in XAML:

Now that my CustomBrush has been defined, it can be re-used in XAML. A given element needs a way to refer to this resource in order to reuse it. This is accomplished by using a markup extension. Markup extensions are a specialized syntax to set a property in a non-standard way, and are recognized by curly braces. For example, let's say the Grid element needs to use the CustomBrush defined above:

	<Grid x:Name="outerGrid" Background="{StaticResource BackgroundBrush}"

In this example, we use a markup extension named StaticResource. Here's (MSDN) some more information about static and dynamic resources

Using a Resource in Code:

In order to use CustomBrush in my code (e.g. C#), I can access the Resources property as a dictionary by using the key to index and retrieve the specific resource.

            Grid outerGrid = new Grid();
            LinearGradientBrush customBrush = 
                (LinearGradientBrush) this.Resources["CustomBrush"];
            outerGrid.Background = customBrush;

I can even update my resource in code. If I wanted to change the color gradient of my CustomBrush, I would do so as follows:

            LinearGradientBrush customBrush = 
                (LinearGradientBrush) this.Resources["CustomBrush"];
            customBrush.GradientStops[0].Color = Colors.Brown;
            customBrush.GradientStops[1].Color = Colors.Red;

The really nifty bit is that every element that uses this customBrush will automatically update to use the new colors.

Silverlight does not support dynamic resources (but WPF does), and as a result it is not possible to update the resource reference with a new object. For example, the following code is not allowed in Silverlight:

            this.Resources["CustomBrush"] = new LinearGradientBrush();

Leave a comment

Filed under .NET, Programming

Custom Attached Properties in Silverlight

An attached property is a type of global property that is settable on any nested object. In Silverlight (and WPF), attached properties are usually defined as a specialized case of Dependency Properties, and like all dependency properties they are managed by the Silverlight property system. Attached properties differ in that they do not have the conventional "property wrapper".

Most commonly, attached properties are used in layout containers. Every control in XAML has its own set of internal properties. However, when this control is placed inside a container, it acquires additional features depending on the type of the container. For example, the Grid.Row property is created as an attached property because any control inside a Grid needs to specify the grid cell where it is positioned. For example:

<Grid x:Name="OuterGrid">
	<TextBox x:Name="innerBox" Grid.Row="1"/>
</Grid>

Since the TextBox is nested inside the Grid, it gains the Row property which "attaches" to the TextBox instance. In essence, attached properties allow different child elements to specify values for a property defined in a parent element. Attached properties always use a two-part name of the form: AttachedPropertyProvider.PropertyName (OR simply DefiningType.PropertyName)

 

Defining a Custom Attached Property:

Creating an attached property is similar to how we create a custom dependency property with a few subtle differences. Since I seem to love widgets so much, I will continue to use a custom WidgetControl as an example. In one of my previous posts we saw how to create a custom dependency property for WidgetControl. In this post, we will see how to create the WidgetStateProperty as an attached property.

1. The first step is to define a static readonly DependencyProperty object that represents the property, and register this attached property with Silverlight. This is done via the Dependency.RegisterAttached() method.

        public static readonly DependencyProperty WidgetStateProperty =
            DependencyProperty.RegisterAttached(
                "WidgetState",
                typeof(Boolean),
                typeof(WidgetControl),
                new PropertyMetadata(false));

Notice that when we were creating custom dependency properties, we used the DependencyProperty.Register() method. The parameters for both these methods are exactly the same: the property name (WidgetState in this example), the data type used by the property (bool), the type that owns this property (WidgetControl), and a PropertyMetadata object that provides additional information, such as default values.

2. Our attached property provider must also provide static GetXXX() and SetXXX() methods, where XXX is the name of our property (WidgetState).

        public static void SetWidgetState(UIElement element, Boolean value)
        {
            element.SetValue(WidgetControl.WidgetStateProperty, value);
        }

        public static Boolean GetWidgetState(UIElement element)
        {
            return (Boolean)element.GetValue(WidgetControl.WidgetStateProperty);
        }

We now have a fully functioning attached property which can be set using the DefiningType.PropertyName syntax. The complete code for this WidgetControl is shown below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace Attached
{
    public partial class WidgetControl : UserControl
    {
        public WidgetControl()
        {
            InitializeComponent();
        }

        public static readonly DependencyProperty WidgetStateProperty =
            DependencyProperty.RegisterAttached(
                "WidgetState",
                typeof(Boolean),
                typeof(WidgetControl),
                new PropertyMetadata(false));


        public static void SetWidgetState(UIElement element, Boolean value)
        {
            element.SetValue(WidgetControl.WidgetStateProperty, value);
        }

        public static Boolean GetWidgetState(UIElement element)
        {
            return (Boolean)element.GetValue(WidgetControl.WidgetStateProperty);
        }
    }
}

Here's a very simple example where we use WidgetControl and its WidgetState property. The code is in XAML:

<UserControl x:Class="Attached.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:local="clr-namespace:Attached"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <local:WidgetControl>
            <TextBox x:Name="txtBox" local:WidgetControl.WidgetState="true">
            </TextBox>
        </local:WidgetControl>
    </Grid>
</UserControl>

Finally, a couple of good resources that talk more about dependecy and attached properties are here [msdn.microsoft.com] and here [www.silverlightshow.net]

Leave a comment

Filed under .NET, Programming

Resolution of Dependency Properties

As I mentioned in my previous blog post, dependency properties depend on any number of services (called property providers) for their values. The Silverlight runtime needs to follow strict rules of precedence to determine the value of a dependency property. This process is called dynamic value resolution.

Here’s a prioritized list of providers in their order of precedence:

1. Animation: If an animation is running and is changing the property value, Silverlight uses the animated value

2. Local Value: If the property value has been explicitly set through XAML or code (by using SetValue or the property wrapper), Silverlight uses the local value.

3. Templated Properties: Silverlight uses the template properties if the object has been built dynamically from templates (ControlTemplate or DataTemplate).

4. Styles Setters: If the page or the application resource defines a Style that applies to the given element, with a Setter for its dependency property, then Silverlight assigns the value from the Setter to the dependency property.

5. Default Value: If no other property setter is at work, Silverlight assigns the default value to the dependency property. If a value is passed in through the PropertyMetadata object during dependency property registration, it will be used as the default value. If no value has been passed in, then the default value depends on the type (reference or value) used for storing that dependency property.

1 Comment

Filed under .NET, Programming

Dependency Properties in Silverlight

Very simply, a property of an element that depends on a number of property-providers outside the element is called a "dependency property". Each of these providers has its own level of precedence. These properties can be either set directly by code, or by one of Silverlight’s services (i.e. property providers) such as animation, data binding, styles etc.

Dependency properties were originally introduced in WPF and are a key concept in both Silverlight and WPF. These dependency features are designed to be read and set in code just like normal properties. However, the internal implementation of dependency properties differs from the implementation of ordinary properties.

To better understand dependency properties, let’s consider an example (this example has been taken and modified from this excellent blog post ):

<UserControl x:Class="DependencyProperty.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <ItemsControl Foreground="Red">
            <TextBlock Foreground="Blue">
                1st line of text
            </TextBlock>
            <TextBlock>
                2nd line of text
            </TextBlock>
        </ItemsControl>

    </Grid>
</UserControl>

In this example, we use two TextBlock controls to display two lines of text. The results of running this app are shown below:

Results of running the Silverlight app above

The first TextBlock changes its Foreground property to Blue. Once we run this Silverlight app, we see that the first line of text has blue color, which matches our intuition since we did set the Foreground property to Blue. However, the second line of text is red. This is somewhat surprising (especially for folks who are new to WPF/Silverlight). I never set the Foreground property of the second TextBlock , so why is it red?

This is an example of dependency properties. Foreground of a TextBlock is a dependency property and the Silverlight runtime sets it to red, which is the value of the Foreground property of the encapsulating ItemsControl .

Defining a Dependency Property

The syntax for creating a dependency property is different than creating an ordinary .NET property. Let's look at how to add a dependency property to a custom WidgetControl.

1. The first step is to define the object that represents the property. This is an instance of DependencyProperty class. This object must be defined as static readonly field. By convention, this field has the name of the ordinary property plus the post-fix Property. For example, if my new property is called WidgetState, the DependencyProperty object will be called WidgetStateProperty.

         public static readonly DependencyProperty WidgetStateProperty;

2. The second step is to register the dependency property with Silverlight. This step needs to be completed before any code uses the property, so it must be performed in a static constructor.

        static WidgetControl()
        {
            WidgetStateProperty = DependencyProperty.Register(
                "WidgetState", 
                typeof(Boolean), 
                typeof(WidgetControl),
                new PropertyMetadata(false));
        }

The arguments to DependencyProperty.Register() method are: the property name (WidgetState in this example), the data type used by the property (Boolean), the type that owns this property (WidgetControl), and a PropertyMetadata object that provides additional information. In this example, I am simply passing a default value of "false" to the PropertyMetadata constructor

3. Define a CLR wrapper property whose names matches the name of the dependency property.

        public Boolean WidgetState
        {
            get
            {
                return (Boolean)GetValue(WidgetStateProperty);
            }
            set
            {
                SetValue(WidgetStateProperty, value);
            }
        }

We now have a fully functioning dependency property which can be set just like any other .NET property using the property wrapper

	widgetCtrl.WidgetState = True;

OR, using XAML:

        <cnmspc:WidgetControl x:Name="widgetCtrl" WidgetState="True">
        </cnmspc:WidgetControl>

The complete code for this WidgetControl is shown below:

    public partial class WidgetControl : UserControl
    {
        public WidgetControl()
        {
            InitializeComponent();
        }

        public static readonly DependencyProperty WidgetStateProperty;

        static WidgetControl()
        {
            WidgetStateProperty = DependencyProperty.Register(
                "WidgetState", 
                typeof(Boolean), 
                typeof(WidgetControl),
                new PropertyMetadata(false));
        }

        public Boolean WidgetState
        {
            get
            {
                return (Boolean)GetValue(WidgetStateProperty);
            }
            set
            {
                SetValue(WidgetStateProperty, value);
            }
        }
    }

5 Comments

Filed under .NET, Programming