Brendan Enrick

Daily Software Development

Custom Model Binders in ASP.NET MVC

In ASP.NET MVC, our system is built such that the interactions with the user are handled through Actions on our Controllers. We select our actions based on the route the user is using, which is a fancy way of saying that we base it on a pattern found in the URL they’re using. If we were on a page editing an object and we clicked the save button we would be sending the data to a URL somewhat like this one.


Notice that in our route that we have specified the name of the object that we’re trying to save. There is a default Model Binder for this in MVC that will take the form data that we’re sending and bind it to a CLR objects for us to use in our action. The standard Edit action on a controller looks like this.

public ActionResult Edit(int id, FormCollection collection)
// TODO: Add update logic here

return RedirectToAction("Index");
return View();

If we were to flesh some of this out the way it’s set up here, we would have code that looked a bit like this.

public ActionResult Edit(int id, FormCollection collection)
Profile profile = _profileRepository.GetProfileById(id);

profile.FavoriteColor = collection["favorite_color"];
profile.FavoriteBoardGame = collection["FavoriteBoardGame"];


return RedirectToAction("Index");
return View();

What is bad about this is that we are accessing the FormCollection object which is messy and brittle. Once we start testing this code it means that we are going to be repeating code similar to this elsewhere. In our tests we will need to create objects using these magic strings. What this means is that we are now making our code brittle. If we change the string that is required for this we will have to go through our code correcting them. We will also have to find them in our tests or our tests will fail. This is bad. What we should do instead is have these only appear on one place, our model binder. Then all the code we test is using CLR objects that get compile-time checking. To create our Custom Model Binder this is all we need to do is write some code like this.
public class ProfileModelBinder : IModelBinder
ProfileRepository _profileRepository = new ProfileRepository();

public object BindModel(ControllerContext controllerContext,
ModelBindingContext bindingContext)
int id = (int)controllerContext.RouteData.Values["Id"];
Profile profile = _profileRepository.GetProfileById(id);

profile.FavoriteColor = bindingContext

profile.FavoriteBoardGame = bindingContext

return profile;


Notice that we are using the form collection here, but it is limited to this one location. When we test we will just have to pass in the Profile object to our action, which means that we don’t have to worry about these magic strings as much, and we’re also not getting into the situation where our code becomes so brittle that our tests inhibit change. The last thing we need to do is tell MVC that when it is supposed to create a Profile object that it is supposed to use this model binder. To do this, we just need to Add our binder to the collection of binders in the Application_Start method of our GLobal.ascx.cs file. It’s done like this. We say that this binder is for objects of type Profile and give it a binder to use.

ModelBinders.Binders.Add(typeof (Profile), new ProfileModelBinder());

Now we have a model binder that should let us keep the messy code out of our controllers. Now our controller action looks like this.

public ActionResult Edit(Profile profile)

return RedirectToAction("Index");
return View();

That looks a lot cleaner to me, and if there were other things I needed to do during that action, I could do them without all of the ugly binding logic.

July HudsonSC

The Hudson Software Craftsmanship Group will be meeting July 20, 2011 at 6:00 p.m. with people arriving as early as 5:30. As usual, we will be ordering pizza, and some of us will be gathering at Kepner’s Tavern after the event to continue our discussions.

If you haven’t attended HudsonSC yet, I highly recommend the group. We have a fantastic group of software craftsmen who are always trying to improve their skills as developers. If you’re interested, please sign up to let us know you’re attending. We will also not turn people away at the door, so feel free to just show up for the event.

The event is located in downtown Hudson at 102 First Street. When you enter the building, just go to the second floor and turn right. Keep walking straight, and you will arrive in our meeting room.

This month I am going to suggest to the group that we try an AppKata instead of our usual programming exercises. These focus more on real-world scenarios and include changing requirements.

We are very loose with our agenda, so if you want to bring in something to talk about or an activity to do, go for it. In fact, you can show up and suggest topics and ideas for that day’s meeting.

See you there!

Rock Paper Azure Contest Bot Tips

A Rock Paper Scissors tournament is being put on by the Windows Azure team. The competition is a fun challenge designed to be a fun way to compete against other developers for some bragging rights. If bragging rights aren’t enough for you, there are prizes also being given out.

1st: XBox 360 / Kinect bundle
2nd: Kinect
3rd: $50 Gift Card

To join the competition, you just have to download the starting code and set up an Azure account to submit your code. They have detailed instructions on the site. You can use a code to get the Azure account set up for free.

How the Rock Paper Azure Game Works

You might be asking, isn’t Rock Paper Scissors just random? Basically, yes. Against a human opponent there will be trends, but with a computer you can be far more random. There are a couple of adjustments made to the game.

To win the tournament, you have to beat the most number of other bots. Beating a bot means that you play RPS until one player wins at least 1000 points. If there is a tie on a point, then the winner of the next point wins the points for the tie as well. This means that if you can get a few ties in a row and then win, you can win a lot of points.

How do you win ties? They’ve added a new move called “Dynamite” That move beats all of the basic moves: Rock, Paper, and Scissors. You can only throw Dynamite 100 times per match, so use it wisely.

Isn’t the dynamite broken? No. They’ve also added a move called “Water Balloon”, which only beats dynamite. You can use as many Water Balloons as you want, but be careful they’re beaten by all of the standard moves.

Rock Paper Azure Bot Tips

Look at Log Files

When you submit your bot to the Rock Paper Azure competition and view the log file from each match your bot had with each other. It will show each point in the game, what each player did, and who got the point. Make sure you’re checking games you lose to see why you lost and also examine some games that you won. This is important so you can see which decisions you’re making that help you win.

Tell Yourself Why You Made Each Choice

You are able to write to the log yourself. If you decide to use Dynamite or a Water Balloon, print out a log message telling yourself why you did it. Then take a look at the log of a game and see if you made the right or wrong choice and adjust your bot accordingly.

Don’t Throw Too Many Water Balloons

A problem that I’ve seen with a lot of bots is that they throw too many water balloons. If I can make my bot trick yours into throwing Water Balloons, I will. Be careful of these tactics (my bot sometimes uses them).

Tactics to use and watch out for:

  • Use only 99 dynamite, because your opponent’s algorithm will keep throwing water balloons.
  • Have an intentional gap where you don’t use dynamite. If your opponent was trying to predict your dynamites they will throw some water balloons and you will win.
  • Start delaying your dynamite throws if your opponent starts water ballooning you.

Don’t Be Too Predictable

This sounds obvious, but I’ve seen plenty of bots which are not using random move selection, I write code to defuse them specifically. There was one bot which always countered your last move, so if you do the same move twice he beats the second one. I wrote the code to disable him and he only got 1 point against me after that.

Write More Than One Strategy

My bot has more than one strategy. I have Water Balloon strategies and Dynamite Strategies. Essentially, my bot is able to change how it decides on water balloons and how it decides dynamite based on information at runtime. What this lets me do is either change strategies mid game or select certain tactics to face certain opponents. I am able to check the name of the bot I am facing and use the strategy designed to beat them.


Go give the competition a shot. There are prizes for the next couple of weeks. Go get a free Azure account set up and see how well you do.

NimblePros is Hiring Developers

NimblePros is looking for new team members as passionate about writing great software as we are. We don’t believe in writing crappy code, and our team is always improving in order to write better code. We continually adjust our processes to promote our goals of reducing waste and delivering better software.

I enjoy working with the NimblePros team, because they’re a fun group of individuals working towards the same goals I am.

If you would like to join the NimblePros team, you can contact us directly by emailing Please let us know what interests you about joining our team and what you’re really passionate about.

Here are a few tidbits about us:

The NimblePros team was founded by our area’s Microsoft Regional director, Steve Smith.

We believe that board gaming is great way to build a cohesive team.

NimblePros sponsors and its team runs the local Software Craftsmanship group.

Why to Join a Software Craftsmanship Group

Like other professional community groups, a software craftsmanship group is supposed to offer benefits that would make a working professional take time from their schedule to attend. These benefits come in many forms: networking, support, feedback, education, self-improvement, and the list goes on. Not all of these benefits will resonate with everyone, and there are plenty that I did not name applying to many individuals and situations. A software craftsmanship group can supplement or replace an existing group that you’re attending.

A common complaint that I hear from attendees of other groups is about how the discussions at dinner after the meeting is the most worthwhile part of the meeting. When I hear this, my first instinct is that these people need to start going to software craftsmanship meetings in addition to or instead of their current groups.

What is Software Craftsmanship?

Software craftsmanship is often described as a movement in the software industry of like-minded people who believe in a set of values which can improve the software we write. The Software Craftsmanship Manifesto describes in what these like-minded individuals believe.

I’ve often found it interesting how the Software Craftsmanship movement seems to be an extension of the agile software development movement. I and most of the members of the Hudson Software Craftsmanship group are all developers who either work at companies follow some form of agile development or are trying to move towards it. In fact the 4 main values described in the Software Craftsmanship Manifesto specifically describe how in the attempt to achieve the values described by the Agile Software Manifesto these ones were found to be indispensible. It is the idea that pursuing one set of values that have proven to be very useful, another set has been found to be extremely valuable.

Dispelling Misinformation

There are some people who have bad opinions of software craftsmanship, and I’d like to take some time to address some of those concerns incase any readers have heard of them or share them.

It’s not elitist.

I’ve heard software craftsmanship referred to as being elitist. In my experience, this is entirely not the case. I would believe that there are people among the community that fit this description, but those people would be outliers. We are welcoming of people of all skill levels who are looking to write cleaner, better software. I for one don’t even think that everyone will or even should be software craftsmen. If you enjoy the way you’re doing this, by all means continue. I don’t believe that my methods, practices, values, and beliefs are any better than anyone else’s. We are a group that shares our beliefs and want to work together to improve ourselves.

It’s not ALT.NET.

I’ve heard Software Craftsmanship compared to ALT.NET by some people, and I can see why the comparison would be made. Both are movements in the software industry to try to do things better than we have been doing them in the past. The ALT.NET community is like-minded individuals in the .NET community who are against the direction, guidance, and tooling that has/had been coming from Microsoft. While I do not follow that guidance either, I am not openly against it. In fact, I realize that the methods that I believe in and use in my own development will not work for everyone.

Software Craftsmen will help each other move away from that tooling and guidance, because the people we are helping want to move away from it. For many developers the control-based, do everything for me approach that often comes with that tooling is perfectly acceptable. There are many developers who are not going to follow the SOLID principles, and they’re not going to be inverting dependencies and writing unit tests either. That’s OK! Other people are not wrong just because I think I can write better code by doing things differently.

It’s not just about code.

Many developers are afraid that software craftsmanship places too much of a focus on writing code. From looking at software craftsmanship from the outside, this is a very valid argument to make. It is, however, mostly based on what is made visible from outside.

The aspects of a software craftsmanship group meeting which people go home and blog about tend to be the katas, exercises, and techniques. Why? Because it is not as easy to bottle up a great blog post on an open discussion among a large group as it is to post about some cool programming exercise. Our community as a whole also tends to really like posts showing source code, so people return from the meeting and post their exercise results. We’re more about thinking and improving our entire development process than just code.

We focus on the micro through programming as well as the macro through community involvement. We focus on how to improve as a business, how to work better with our clients, customers, and peers, and how to do all of this slowly with manageable, incremental change.

What Happens at a Craftsmanship Group?

Our main focus at a software craftsmanship group is to reinforce the skills, beliefs, values, and principles of our members. We have discussions, which are based on topics in the industry. We want everyone thinking, questioning, and improving. We don’t want you to even accept things that other craftsmen tell you. Go to the meeting ready to question others. We need to back up our thoughts and ideas, and most of all we need to be willing to try new things.

Why lightning talks?

Most user groups feature a single person transferring knowledge to the masses who attend the group. In these situations the knowledge flow is unidirectional, and we don’t find that to be as effective as having people of all skill levels discussing the topic. A lightning talk is a great way to introduce a topic by spending 5 to 10 minutes discussing introducing the topic briefly. These talks then open the floor for immediate continued discussion or become ideas for later open discussions at the group.

Why open discussions?

Discussions allow us to share our ideas and get feedback on them. We will often discuss values and principles of craftsmanship. We also use this as a chance to discuss how we’re each solving some similar challenge we’re all facing. Some topics we’ve done in the past revolve around automated unit testing. These often are focused on some type and how to do them better. I recently was involved in a craftsmanship discussion revolving around the concept of BDD and went from low to high level. Some topics deal less with coding than the infrastructure we as developers depend on like our continuous build implementations and our database change management systems. Other common topics deal with how to get buy-in from a business to follow the practices that we believe to be beneficial.

Why code katas?

A kata is designed to give you a consistent experience doing the right things. Like the martial arts equivalent it is not something you would use in a real-world situation, but it is designed to emulate one. It goes through a set of steps where a master of the art has imparted wisdom by showing the steps to be taken when presented with certain challenges. These katas will let you know how and why the master takes certain steps at certain points and are designed to be repeated so that we immediately respond with the correct solution when presented with a certain challenge.

Why programming exercises?

We have all learned to program, and we need to keep ourselves in practice. No, our day jobs are not practice. Exercises are designed to give us practice so that we have recent experience solving challenging problems to assist in our everyday programming tasks. Many people believe that comparing software developers to musicians or athletes is a stretch, and I will agree with them that there are great differences between these groups. We are, however, all skilled individuals and if we’re even remotely similar to the musician or the athlete, then we need to also be practicing.

I’ve been presented with many real-world challenges where I say, “I can use the same technique here that I use when solving the Greed kata.” That being one example of a programming exercise where I have tried solutions and found some that work very well with the practices and techniques that help me write cleaner code.

What should I do next?

Find a local group of software craftsmen. If there is not one in your area or the one in your area is more than an hour drive to get to, then start one. Gauge the interest, and start making noise about it. Other people interested will join the group, share their ideas, experiences, and trials, and keep the group interesting.

Good luck!

The Software Craftsmanship group that I run is located in Hudson, OH. We are between Cleveland and Akron, and we have members from both of those locations. If you're in the area, we look forward to seeing you at one of our events.

Go Try NuGet. Seriously.

NuGet is best described as the tool from Microsoft that lets you add references to your project directly from the NuGet feed while storing and managing them locally. It lets you keep your references local to your source code, which will help you keep your software project encapsulated. When a package you use gets an update, you can ask NuGet to update your local version of the package.

When telling people about NuGet it is important to explain how powerful it really is. NuGet is not just a collection of libraries to include in your bin folder. It will actually install the package into your project. I will show you what I mean.

Installing NuGet

NuGet can be installed through the Visual Studio Extension Manager. From within Visual Studio, open the Tools menu and select Extension Manager. Once in that window, select the Online Gallery and search for “nuget”. Then you just have to tell it to Download nuget. This will require a restart of Visual Studio.


Using NuGet to Install a Package

Now that NuGet is installed we can start using it. There are two ways to do this, and I will start with the one that is the easiest. All we need to do is right click on out project’s references folder and select “Add Library Package Reference…”


From the window that opens, we want to make sure that we select the Online section on the left and select All. Now we use the search box to search for the package that we’re trying to install. And we click the Install button. NuGet will get the package you requested as well as any Dependencies listed. Notice in the following image that WebActivator is listed as a dependency of this package. NuGet packages will often add files other than just dlls to your solution. Isis, which is the package shown here will also include its own bootstrapper, which will allow Isis to have routes mapped for itself, so you can begin using the application immediately.


Viewing the Results of Installing a Package From NuGet

Thanks to packages being able to includes these files allowing themselves to be automatically configured, I already have the Isis ASP.NET Control Panel installed. It’s not just a reference in my bin folder, it also gave me this bootstrapper file. I don’t have to do any extra work installing Isis.


Thanks to NuGet getting me all the files I can navigate to the Isis ASP.NET Control and begin using it immediately.


There is also a command line interface for NuGet. If that is your cup of tea, then I recommend checking it out instead.

The Isis ASP.NET Control Panel

In case you are wondering about the Isis package that I installed, it is a relatively new Open Source project based on a few projects that Steve Smith and I have worked on in the past. We are creating an ASP.NET control panel which can be easily installed (as you’ve seen already) into any ASP.NET application and provide tools to help manage, develop, and diagnose the application.

IIS 7 Not Serving Static Files

I learned this potentially very useful bit of information from Scott Forsyth recently. As you may know, IIS 7 is modular, which allows for a great deal of control and customization of an IIS installation. There are a lot of other great benefits also. Web servers are great tools that allow us to put our content on the web. One of the most powerful things is their support for creating dynamic sites through different programming frameworks and languages. We sometimes take for granted our having static content in our web server. The static content is all of the common content on a site, which is not dynamic. In general this means our htm, html, and image files.

If you’re ever not serving that content then you should make sure that your IIS installation is set up to serve that content using these steps.

Open up the control panel and click on the Programs category.


Click on “Turn Windows features on or off” in the Programs and features section.


Expand in the tree view in this order: Internet Information Services, World Wide Web Services, Common HTTP Features. Then make sure that Static Content is checked.


If that was unchecked and you checked it and clicked OK, then you should be all set and serving static files like images and html pages in your web site.

Not really sure why someone would want to turn that off, but at least it is easy to turn that setting back on.

Some Thoughts on Software Craftsmanship

I've been reading plenty of blog posts about Software Craftsmanship including a nice response by Uncle Bob. I ran a Software Craftsmanship precompiler workshop at CodeMash again this year, and I've even seen some good feedback and follow up from attendees. If you're in the area, I really recommend coming out to CodeMash next year. I am hoping to be there again next year doing the Software Craftsmanship precompiler.

Back in 2009, Steve Smith, Rich Henning, and I got together and discussed how we were going to create the Hudson Software Craftsmanship group. We figured out some times to meet and what types of exercises we would do. The group has had a steady group of attendees over this time period. We use a room that if we're prepared can fit about 30 people. Our usual group is between 15 and 25 people who show up ready to discuss software craftsmanship, values, principles, practices, unit testing, quality, and just about anything else. We get just enough people to have some really great discussions. Our next meeting is actually tonight and right now we have 28 people signed up for the event. We found some things to focus on and we did. We're all about lightning talks, discussions, and improving our coding abilities. 

In short, I've got Software Craftsmanship on the mind right now. I might as well spend some time discussing it.

I think Software Craftsmanship started as a good banner to rally behind in the fight to end crappy code. There are plenty of reasons why code might have been crappy, and I am all for rallying behind the banner of good, clean code. We're not talking about agile or lean when we talk about Software Craftsmanship, however, most craftsman are also supporting lean practices. In software craftsmanship we focus on the people, their relationships, and the code they write. I think in this sense, Software Craftsmanship can apply for any agile methods you use or even on a waterfall project. We're talking about writing code that fits the situation, which means in a lot of cases we need to cut down on the crap. We're more than that though. We're about making customers happy (sometimes the customers are just our bosses.) We are also trying to become better developers as a community. We need to help each other. The best developers in the world are the ones who have learned from other developers. You can never be great if you don't learn from others.

One of people's favorite terms to use is quality. It really has a meaning that is easy to define in generic terms, but is very difficult to nail down in terms if a quantity. I think we could all define quality in some way, but I think that we cannot determine the quality of code very well. It is very subjective, since people's definitions of quality and how they apply it are different. I think, however, that it is a central point in Software Craftsmanship. For that reason it is something that we should strive to understand and evaluate. If I were to give an important trait for a Software Craftsman to have it is the ability to determine and evaluate quality. Use whatever measure you like, but be able to understand quality and how to evaluate it depending on the circumstances of the code you're writing. Your definition of quality need not even match everyone else's. 

A topic that I've heard Steve Smith argue with people over plenty of times is whether or not a software craftsman should knowingly write low quality code. This usually comes up when the customer specifically wants you to write crap. The customer might even say that they'd rather have the product done sooner with bugs rather than have the code take any longer. I've heard some good arguments on both sides. To throw my two cents in, I'll just say that it really depends on the situation that you're evaluating.

I didn't have as good of a perspective on this topic until a great discussion on this very topic broke our during a HudsonSC meeting in which Joe Brinkman gave some very good arguments for why a software developer might not want to put extra time into code. His point was that for a startup, there is a better than average chance that you will be throwing the code away soon. You do not know if this code will ever be used again. It might be gone in a few months.

I admit in most situations I would argue for having higher quality code, but in the case of a startup I think there is good reason to write code fast and get something working. I think it is assumed for some startups that their code might have bugs or other issues. My interpretation of what Joe was saying is that the business might not even be a good one, so in those instances the software need only provide the basic functionality of the idea. If it is missing features or has some bugs you can still tell if the idea is something that the market is interested in. Startups have a completely different mindset. You need to quickly and cheaply find out if the business idea is going to work before your run out of funding. If I am interpreting him correctly he is basically talking about throw-away businesses not just throw-away apps. You keep starting and tossing businesses until one of them succeeds. I think in this situation, the code can reflect the business. Once the longevitiy of the business is determined, quality can be brought back into the mix.

To look at things from a different perspective, we can take the groups of people we have that attend HudsonSC who work at banks, insurance companies, and healthcare companies. All of these are long-standing businesses that need to maintain quality code at all times. It is these who have the traditional opinions on SoftwareCraftsmanship. These groups have no reason to lower quality. In fact if they don't maintain quality, they could have serious issues. I think most of us are in the boat where we expect the business we're working for to still exist in 6 months. This means that our code needs to survive and maintain for years after we first write it.

A software craftsman should know what customers want and be able to provide code which offers the value the customer is looking for. It is up to a craftsman to determine what solution is the best one for the job and be prepared to provide the highest quality code possible. In this instance I will say that the level of quality in the code is one that should be determined by the developer and the customer. 

Wire up your ViewModels using a Service Locator

No MVVM solution is complete without having the DataContext bound to a ViewModel, but this wouldn’t be a fun development community if there were not some disagreement on the specifics of how to achieve certain goals. I will be recommending how I like to wire up ViewModels. There are other ways of doing this, but I will explain some of the reasons I use this method.

You can start by building a View that needs to have certain traits in its ViewModel and then create a well-tested ViewModel separately. This ViewModel should have all of the properties and data required by the View. Make sure you also have any commands or other functionality the View will require. It is then your job to make the connection between these two objects. The way I like doing this is by using a Service Locator to give my View the ViewModel it needs. This also gives me a good centralized location where I can make sure that my ViewModels are wired up the way I need them to be.

To create our service model we are going to need to create a class which has methods returning the ViewModels we are using in our Views. We should have one getter per ViewModel to be requested. I tend to use names matching the name of the ViewModel for the getters. The service locator will look a bit like this when you’re done. (You can also use an IoC container in the service locator, which is what I do in all of my production code. In that case you would just use the IoC container rather than instantiating the object as is done in this example.)

Code Listing 1 – The Service Locator:

public class ServiceLocator
public AwesomeViewModel AwesomeViewModel
get { return new AwesomeViewModel(); }

Notice that I can pass in any parameters needed for the ViewModel constructor so my ViewModel can depend on abstractions. The service locator can be more complicated than this if other work needs to be done to create these ViewModels. An example of such a situation is if I have shared dependencies or I am using an IoC container to create my objects.

Now that we have our code written to get us our ViewModel object we need to make this class available to all of our Views. This can be achieved by creating an instance of one of these as a static resource in our App.xaml file. Static resources defined here are easily accessible.

Code Listing 2 – Declaring the Service Locator as a Resource in App.xaml:

<Application x:Class="Awesome.App"
<Awesome:ServiceLocator x:Key="SvcLoc" />

The key that we have assigned to this resource is how we will reference it when we access it later. In other parts of our code we will just specify in our bindings that we are accessing this static resource and calling its properties to get the data that we need. In fact this is exactly how we can get our ViewModel into our View. When we bind our DataContext we will tell it that our source is going to be this ServiceLocator instance and that we are binding our DataContext to a specified path, which is a property of the ServiceLocator.

The binding can be done either of these two ways. I don’t really prefer one or the other. These are effectively the same things, so it really comes down to preference.

Code Listing 3 – Binding the DataContext to the ServiceLocator:

<Binding Path="AwesomeViewModel"
Source="{StaticResource SvcLoc}"/>

Code Listing 4 – Binding the DataContext to the ServiceLocator Inline:

DataContext="{Binding AwesomeViewModel, Source={StaticResource SvcLoc}}"

Now we can access this DataContext throughout our View by just binding to different paths on it.

I like this approach because it keeps the binding in the XAML and not in the code. It is also nice because we are able to bind easily to properties and have these properties do dependency injection for our ViewModels. The centralization of all of this ViewModel creation is also very convenient. We are able to visit this one class to make adjustments for how the entire application handles its ViewModel initialization.

Making Text Clickable in Silverlight for Windows Phone 7

I’ve seen a lot of snippets of code online where people are trying to make text clickable in Windows Phone 7, and plenty of them are using the OnMouseLeftButtonDown event to do it. Well to put this lightly, this is not the best way of handling a click in the Windows Phone 7 environment. The reason is that we have to put the “left button” down in order to scroll. The “left button” is our finger, so if we try to scroll down and press our finger on the text we will be activating the event by mistake.

In order to resolve this we need to have the click event. Well, the click event is on the Button not on the TextBlock. In this example I will be using the MVVM Light toolkit and showing how I can wire up a Click event to a command on my ViewModel.

This example is a DataTemplate being used to display a list of colors each one as a bound item in a ListBox. I will be setting the text of each item to be the name of the color and I will be handling the click event by binding it to a command on my ViewModel the command will take in the color’s ID as a parameter. Notice that since I am in a DataTemplate I have to access the ViewModel for this view by accessing my view. While in the DataTemplate my current DataContext is the Color item I am binding in the list. Read more about accessing the ViewModel from a DataTemplate.

<DataTemplate x:Key="colorListTemplate">
<TextBlock Text="{Binding Name}" FontSize="64" />
<i:EventTrigger EventName="Click">
Command="{Binding DataContext.PickColor, ElementName=TheView}"
CommandParameter="{Binding Path=ID}"/>

Notice that I set the ContentTemplate of the Button. This means that I am telling the control to not display how it would normally display and instead to display how I want it to. I do this so that I can display text as normal so that it looks like a have a regular list of items, and I am able to make this text handle the event when someone clicks on it. Keep in mind that a click and a scroll are two different operations in the Windows Phone, so non one is going to accidentally click on my item when they are trying to scroll. If I had done this with a MouseLeftButtonDown event as I’ve seen shown in the past it will cause the command to happen when someone is trying to scroll the list on the phone.
Remember that a button can look like anything in Silverlight. You have a ContentTemplate you can define for the button, so you have the power to always have a Click event. So if you need to make something clickable, make a button and put your control as the template for the button.