WPF - How to Programmatically Work With Attached Properties

The purpose of this post is to explain how to programmatically manipulate attached properties. I recently learned about them from the XAML side, however, I began to question how to use them from actual code. I really like the fact that XAML essentially maps Objects-to-Elements and Object Properties-to-Element Attributes. Then I saw these attached properties and I had to do some investigating to figure out how to manipulate these types of values from code. It's actually pretty easy, but you have to do it once to know how to do it. So I thought I would share my new found knowledge. The code used in this posting is available here. For an overview of Attached Properties, go here.

As a proof-of-concept, I created an application that simply displays a ComboBox that displays the available columns. The user can select a column and press the "Update" button. When the "Update" button is selected, the ComboBox will move to the selected column. The application looks like the following (I know it's ugly, but I've also been playing with some of the LinearGradientBrush stuff).

The XAML code that is of interest looks like the following (please bear in mind this is just a snippet and not the whole thing):

The Attached Properties in the code snipped used above are Grid.Row and Grid.Column. These properties define where in the grid the ComboBox is displayed. In order to set the attached property from the code behind, I had to essentially use 1 (yes one) line of code in the Click event of the Button. That line of code looks like the following:
Grid.SetColumn(ColumnComboBox, selectedIndex);
selectedIndex is just an integer set from the selected value of the combo box.

The "magic" occurs because Attached Properties essentially call static methods of an object. The static method is always named in the same manner. It is defined as ObjectType.SetNameOfProperty. So from the example, the ObjectType is Grid and the NameOfProperty is Column. Pretty kewl.

Windows Presentation Foundation (WPF) - Why should I use it?

The "why" question was recently asked within the WPF Forum. It is an extremely valid and important question. I think it would be hard to adequately answer this question within a single blog post. However, when trying to explain "why" something is important, I try to stick to a "2-minute" rule. I pretend that I have two minutes to get my point across.

I really believe that WPF spans beyond just eye-candy (though it does let you make some pretty slick looking stuff) and provides value for all types of applications. This post is far from a complete answer to the "why" question, for more information, I would recommend this great article . However, let's pretend I have two minutes to explain to an executive why I believe this platform should be used... (2 minutes begins now).

Productivity - WPF is a unified platform for UI development. Currently, two of the most used UI development infrastructures (ASP.NET and Windows Forms) provide two very different development experiences. If you need a browser-based application, one skillset is needed and if you need a Windows Forms application, another type of skillset is needed. With WPF, acquired UI development skills can be leveraged across varying application types.

Usability - It's been said that "a picture is worth a thousand words" and the built-in animation and media capabilities of WPF provide the opportunity for assisting both learning and experienced application users. Animations can be used to create illustrations that more effectively communicate items such as sales and marketing trends. In addition, the built-in support for a variety of audio and video types can be leveraged to easily distribute "how-to" videos within an application. This is a massive value add that can drastically improve an application's help documentation. If users are frustrated by an application, they are more likely to find an alternative.

Another one of the great features of WPF is the utilization of vector based graphics. Vector based graphics can address the needs of an aging audience that may have less than perfect eyesight, by providing the opportunity for fonts and certain images to scale in size.

Branding - WPF also helps in creating applications that really match the identity of an organization. Take a look at a corporate logo, generally it uses either a non-web friendly font, incorporates curves/rounded edges, and/or a gradient. While all of this stuff can be done on Windows Forms and Web applications, they can be somewhat difficult to accomplish and often times require compromises. With WPF, shapes and gradients are part of the platform! In addition, by utilizing vector graphics, this branding is scalable.

In addition, WPF provides an excellent opportuntiy to get designers involved in the process by incorporating a model/view architecture. By incorporating designers, UIs can be more relevant, more engaging, and more distinct. (thanks goes to Rei Miyasaka for mentioning this in the comments).

Distribution - WPF also provides the opportunity to distribute an application to a wide variety of user end points. For instance, WPF can be used for desktop applications, intranet/internet applications and Windows Media Center applications.

(end 2 minutes).

After two minutes, only the surface has been scratched. However, before ending this post, I want to mention a facet of productivity that I feel is often overlooked, the availability of community. The .NET community is large and growing. Between the user groups, the forums, and the blogs, I believe that the availability of assistance when needed is one thing that makes the this platform standout over others.

Another thing that I feel often gets overlooked is the fact that there is innovation within integration. Often times integration alleviates ambiguity. This alleviation is a massive value-add that is very hard to calculate. However, I feel that the WPF platform really hits on this concept of innovation through integration. There are other platforms that can do similar things. Some of these platforms can do certain things better. However, I believe if you take into account the entire picture, that is where I feel true value of WPF lies.

I look forward to the comments on this post!

Windows Workflow - Design - Best Practice?

The purpose of this post is to define what seems to be a useful approach when designing workflows that contain activities that you may want to reuse, that use some common values. Essentially, I needed something like a "Session" variable within my workflow. If I figure out a better way, I will blog about it, until then...

Essentially, I've been working on a workflow that contains a number of activities that I may want re-use. In order to accomplish this, it is important to develop each activity so that it is autonomous.

The problem that I have run into is, I essentially need something like the "Session" variable from ASP.NET (documentation). Because of the design of the workflow, and the desire to reuse these activities, there are some values that I need to retrieve after an activity is run, through a code activity and use that value in 1 or more activities down the road. Personally, I couldn't find any built in functionality into Windows Worflow to allow you to do this. If someone knows of a better way, please post a comment. For now, you can download the source code that will be used in this post here.

In order to display how I have accomplished this "Session" variable, let's extend the workflow from 11-21-2006 to make our workflow look like the following:

Essentially, the purpose of "myActivity" is simply to set the first/last name information. The purpose of the "codeActivity1" is to create an e-mail address based upon the first and last name entered into myActivity. Finally, "myOtherActivity" is responsible for displaying the user's newly generated e-mail address.

Essentially, it will make the most sense to review the code knowing that:

• We are trying to create "Session" type functionality
• There maybe a better way to do this particular example, however, it's purpose is to display the "Session" type functionality.

Now to walk through the code. The first step is to setup a "Session" variable within the workflow. This step is implemented by inserting the following code into the "MyWorkflow.cs" file.

// Contains the information to be used throughout the workflow
private Dictionary<string, object> session = new Dictionary<string, object>();
public Dictionary<string, object> Session
{
  get { return session; }
  set { session = value; }
}


Next, the "codeActivity1" "ExecuteCode" method is set to call "SetEmailAddress". The "SetEmailAddress" method is defined within "MyWorkflow.cs" and looks like the following:


public void SetEmailAddress(object sender, EventArgs e)
{
  // Pretend that this value is retrieved from some external
  // data source (database, registry, web service, etc)
  string emailAddress = firstName.ToLower() + "." +
    lastName.ToLower() + "@domain.com";
  session["EmailAddress"] = emailAddress;
}


After implementing the preceeding code, the magic happens within the "MyOtherActivity.cs" file. A new method called "HydrateProperties" has been added. This method is called right at the start of the "Execute" method. "HydrateProperties" is defined as follows:

private void HydrateProperties()
{
  // Retrieve the root activity (the actual workflow activity)
  Activity workflowActivity = this;
  while (workflowActivity.Parent != null)
    workflowActivity = workflowActivity.Parent;
  MyWorkflow myWorkflow = (MyWorkflow)(workflowActivity);

  // Based upon your precedence needs, you may want to only set a property from
  // the session if it has not been set from the workflow designer. If you want to set
  // the property no matter what, just remove the "if" statement.
  if (EmailAddress.Trim().Length == 0)
    EmailAddress = Convert.ToString(myWorkflow.Session["EmailAddress"]);
}


That's it! I hope this helps and if you come across a similar situation. In addition, if you know of a more recommended approach, please post some info within the comments.

You can download the source code for this example here.

WPF - How to get started with WPF/E (Dec CTP)

Below is the fastest step-by-step approach for beginning to develop WPF/E applications on a machine that has Windows XP SP2 and Visual Studio 2005 installed:

• Download and install the update that allows Microsoft Visual Studio to support web application projects.
• Download and install the web projects add-on for Visual Studio 2005.
• Download and install the "WPF/E" SDK.
• Run Start->All Programs->WPFE SDK->Tools->Install WPFE VS Template.

If you have ran these steps, you should be able to start Visual Studio 2005, go to File->New->Project... and see something like the following:

WPF - WPF/E CTP is Open for Business

It's a very exciting day if you've been anxiously awaiting on WPF/E!

The DevCenter Page is here!

Windows Presentation Foundation - Forums - Achievement Unlocked

Well, much to my surprise, I logged into the MSDN WPF Forum this morning and I noticed that have made the top 10 answerers list.

I'm excited to help out the developer community! Keep the questions coming.