RelayCommand, Yes Another One!

Another RelayCommand

First thing first I want to point out that there are many implementations of the Relay/Delegate command out there to choose from. My two personal favorites are Josh Smiths RelayCommand and of course the DelegateCommand from the Prism Library. That said, both of them miss things that many of my projects have required and as a result I have had to either extend, or roll my own. So in this post I am going to add to the mix yet another implementation. I presented this implementation earlier this month as part of my MVVM discussion with the folks at the Mankato .Net User Group and a few people afterwards asked me about it so I have decided to make it public.

Use it if like or take and change it so it fits your needs more appropriately. Either way no warranty for you!

Why Relay

Relay commands are very basic implementations of the ICommand interface. WPF people may say what about RoutedCommand? Well, there are several reasons you don’t want to use RoutedCommands in our ViewModels, the most obvious is because they route! Aside from that they rely on the creation of a CommandBinding, and at the end of the day it’s just not real clean.

RelayCommand makes it very easy for our ViewModels to create command instances that our Views can bind to. At the same time RelayCommand with its delegate support allows our ViewModels to control the command implementation details. This helps make our code more testable, and limits the command class explosion that happens if you start creating a class for each command.

What Relay

So what do I want my RelayCommand to do? Below is a list of features that are not native to many other implementations that I find I cannot live without.

1. Built-in support for Asynchronous processing (Fire and Forget, or with a Callback/Continuation)
2. Supports ‘busy’ cursor behavior when running Synchronously
3. Supports Predicate and Action delegate so ViewModels can own the implementation details
4. Hooks into the CommandManager’s RequerySuggested event so ViewModels don’t have to raise the CanExecuteChanged event all the time.

So let’s take a look at the code that accomplishes this.

using System;
using System.Threading.Tasks;
using System.Windows.Input;

namespace Commanding
{
	public class RelayCommand : ICommand
	{
		#region Private Data Members

		/// <summary>
		/// Flag indicates that the command should be run on a seperate thread
		/// </summary>
		private readonly bool mRunOnBackGroudThread;
		/// <summary>
		/// Predicate that that evaluates if this command can be executed
		/// </summary>
		private readonly Predicate<object> mCanExecutePredicate;
		/// <summary>
		/// Action to be taken when this command is executed
		/// </summary>
		private readonly Action<object> mExecuteAction;
		/// <summary>
		/// Run when action method is complete and run on a seperate thread
		/// </summary>
		private readonly Action<object> mExecuteActionComplete;

		#endregion

		#region Constructor

		/// <summary>
		/// Initializes a new instance of the <see cref="RelayCommand"/> class.
		/// </summary>
		/// <param name="canExecutePredicate">The can execute predicate.</param>
		/// <param name="executeAction">The execute action.</param>
		/// <param name="executeActionComplete">The execute action complete.</param>
		public RelayCommand(Predicate<object> canExecutePredicate, Action<object> executeAction, Action<object> executeActionComplete)
			: this(canExecutePredicate, executeAction, true)
		{
			if (executeActionComplete == null)
			{
				throw new ArgumentNullException("executeActionComplete");
			}
			mExecuteActionComplete = executeActionComplete;
		}

		/// <summary>
		/// Initializes a new instance of the <see cref="RelayCommand"/> class.
		/// </summary>
		/// <param name="canExecutePredicate">The can execute predicate.</param>
		/// <param name="executeAction">The execute action.</param>
		/// <param name="runOnBackGroundTread">if set to <c>true</c> [run on back ground tread].</param>
		public RelayCommand(Predicate<object> canExecutePredicate, Action<object> executeAction, bool runOnBackGroundTread)
			: this(canExecutePredicate, executeAction)
		{
			mRunOnBackGroudThread = runOnBackGroundTread;
		}

		/// <summary>
		/// Initializes a new instance of the <see cref="RelayCommand"/> class.
		/// </summary>
		/// <param name="canExecutePredicate">The can execute predicate.</param>
		/// <param name="executeAction">The execute action.</param>
		public RelayCommand(Predicate<object> canExecutePredicate, Action<object> executeAction)
		{
			if (canExecutePredicate == null)
			{
				throw new ArgumentNullException("canExecutePredicate");
			}

			if (executeAction == null)
			{
				throw new ArgumentNullException("executeAction");
			}

			mCanExecutePredicate = canExecutePredicate;
			mExecuteAction = executeAction;
		}

		/// <summary>
		/// Initializes a new instance of the <see cref="RelayCommand"/> class.
		/// </summary>
		/// <param name="executeAction">The execute action.</param>
		public RelayCommand(Action<object> executeAction)
			: this(n => true, executeAction)
		{

		}

		#endregion

		#region ICommand Members

		/// <summary>
		/// Occurs when changes occur that affect whether or not the command should execute.
		/// </summary>
		public event EventHandler CanExecuteChanged
		{
			add { CommandManager.RequerySuggested += value; }
			remove { CommandManager.RequerySuggested -= value; }
		}

		/// <summary>
		/// Defines the method that determines whether the command can execute in its current state.
		/// </summary>
		/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
		/// <returns>
		/// true if this command can be executed; otherwise, false.
		/// </returns>
		public bool CanExecute(object parameter)
		{
			return mCanExecutePredicate(parameter);
		}

		/// <summary>
		/// Defines the method to be called when the command is invoked.
		/// </summary>
		/// <param name="parameter">Data used by the command.  If the command does not require data to be passed, this object can be set to null.</param>
		public void Execute(object parameter)
		{
			using (new BusyCursor())
			{
				if (!mRunOnBackGroudThread)
				{
					mExecuteAction(parameter);
				}
				else
				{
					if (mExecuteActionComplete != null)
					{
						//Run with continuation
						var context = TaskScheduler.FromCurrentSynchronizationContext();
						Task.Factory.StartNew(mExecuteAction, parameter).ContinueWith(mExecuteActionComplete, context);
					}
					else
					{
						//Run as fire and forget
						Task.Factory.StartNew(mExecuteAction, parameter);
					}
				}
			}
		}

		#endregion
	}
}

Constructors

There are several overloaded constructors for this class; each of them implies how the command should behave (Sync or Async). This allows our ViewModels to dictate how these commands should function upon construction time.

Delegates

One of the core goals of an implementation like this it to allow the details of each command to remain in our ViewModels, the Predicate, and Action delegates help us with this quite nicely. Making the parameters to these delegates generic could make this even more flexible but the this example I have left that out.

CanExecuteChanged

Looking at the CanExecuteChanged event, notice how the CommandManager.RequestSuggested event is being wrapped. This is very nice because we put the burden of raising the CanExecuteChagned event on the shoulders of WPF. Additionally the RequestSuggested event is static so it will only hold onto our handlers as a weak reference, so we are good from a memory leak perspective.

Execute

The magic all comes together here, some simple logic to determine how the supplied Action delegate will be executed. Maybe it’s synchronous (with a busy cursor) maybe it’s asynchronous. Maybe a callback is executed once the work put on a separate thread is complete, maybe its fire and forget. All this goodness is dependent on the constructor you decided to call when you created your instance.

Summary

So while not earth shattering, this is the implementation (or a slight variance of it) that I use in most of my WPF projects. The command supports the provider concept by using delegates, sync and async processing, and leverages the command manager to raise the CanExecuteChanged event handler in a memory safe way. Hopefully you will get some use out of this.

 

 

Don’t Play With the Monkeys (Ice-Breaker)

The year was 2010 and the location was Botswana Africa inside a wild game reserve just south of the Zimbabwe border. I was walking back to our camp site from the showers wearing only the towel around my waist when I inadvertently crossed paths with a monkey that was tending to her young. Unhappy with my presence she lunged at me chasing me back into the shower area. As I stared at the hissing monkey now blocking my exit I began frantically calculating my options.

1. Run into the shower stall, but that would offer little protection
2. Try and run past the monkey, but wearing only a towel and flip flops this was great option
3. I could wait, risking a confrontation with the monkey.

It was at this point I asked myself how on earth did I get end up here?

To answer that question I have to go back to 8^th grade when my parents reluctantly purchased me my first guitar. I say reluctantly because my general pattern was to lose interest in everything I started very quickly. This was not the case with guitar however. I became obsessed with it; at school I joined the Jazz band, outside of school I played in rock bands, I started taking lessons two times a week, and even started to learn how to build them.

It was my obsession with guitar that led me to college. Mostly interested in Classical guitar by this time, I enrolled at the University of River Falls, while a school mostly known for agriculture they also have one of the best classical guitar instructors in the Midwest. Music became my life, six hour days in the practice rooms, music theory parties, composition contests it was a great time in my life.

About two years into my study, my guitar teacher expressed interest in developing a web site for his group the Minneapolis Guitar Quartet. Knowing absolutely nothing about computing at that time and even less about web development I volunteered to do it. Using my roommate’s computer and a HTML book from the computer science department’s library I built my first website. It was at this point that I found yet another obsession. Programming! Shortly after that I added an additional major in computer science. This was the happiest day of dad’s life, since he had hopes that I could actually get a job after college.

Fast forward 4 years, with my music degree and computer science degree in hand, I found myself in Winona, MN working as a web developer for a company called Fastenal. It was here where I met a woman from India name Pragya who after several months of begging finally agreed to go out on a date with me. While it’s true I begged for the first date, I want to make sure to state that it was her who asked me to marry her! In 2005 Pragya and I were married in New Delhi India, in a traditional Hindu wedding.

By now you must be thinking, what does this all have to do with the Monkey? I promise I am getting there!

When my wife came to Iowa for college her parents left India to start a manufacturing company in Africa. With half of her family in India and her parents in Africa we travel to both places quite a bit. In 2010 we went to Africa, and traveled to the Chobe game reserve for a safari, and this is where I found myself face to face with the angry monkey.

So how did I get here? My parents got me a guitar, guitar led me to college, college let me to computing, computing led me to Pragya, and Pragya let me to Africa and Africa to this very angry monkey.

So what happened? Well just as the monkey was about to lunge at me, out of nowhere a man with a big broom smacked the monkey out of the door way. The man started at me and said, “Don’t play with the monkeys”

 

Frameworks and Austrian Economics

Inception

An interesting thing happened to me a few years back while sitting in a Sprint Retrospective. A nameless developer on our team voiced some frustration with our UI Framework. Person X stated that that the UI Framework was too constraining. Since I was largely responsible for this aspect of the system I was interested in hearing the developers concerns. When pressed to describe the areas Person X felt were too limiting, it became clear that the developer was trying to work out of band and out of pattern. The developer was trying to introduce a new UI pattern not yet discussed or agreed upon by our team and users.  It was in this moment it occurred to me that while frameworks need to support the needs of the system, they should also prevent developers from introducing things that are not well understood at a whim.  This particular conversation was the seedling for my particular view of how frameworks should support applications. I call it Framework Organics.

What is the Role of a Framework

This question will likely elicit 10 different answers if you ask 10 different people. And though you did not ask here is my answer.

A framework should box developers into the understood and agreed upon patterns while allowing for the necessary changes agreed upon over time.

In greater detail a framework should provide support for concepts that are relevant to the system being developed. In stark contrast a framework absolutely should not support any random concept a developer can dream up. It should limit the ability of developers to travel to far off into the weeds. Protecting your users from cowboy coders who are spinner happy!

Along with limiting developers from introducing new concepts, a well-designed framework should be able to adapt to change over time. It should be resilient and extendable to meet any reasonable need that may arise throughout the development lifecycle. This does not mean that you need to build an over engineered goliath of a framework that supports every possible permutation possible. Because you can’t and no one I have ever met can.

Organics and Austrians

One of my favorite economists F.A. Hayek wrote an entire book called ‘The Fatal Conceit’. In this book he makes the case against socialism. Political affiliation aside his premise is worth mentioning here. Hayek believed as many Austrian Economists did/do, that it was impossible for central planners to understand that millions of interactions of the millions of people they govern. He also argued that any attempt to plan around these interactions was a form of conceit that was doomed to fail. Austrians believe that the framework of society was grown overtime in a free market sort of way. If problems came up they were addressed and solved, it was this sort organic evolution that Austrians feel allow us to strive as we do today.

Again this is not meant to be a political rant. But parallels can be drawn between concepts in software design and economics.  The Agile Method and the various approaches of iterative development it has spawned clearly harness the power of organic growth over time. Short cycles of problem/solution/repeat are much more in line with Hayek’s ideas than they are with say the Keynesian approach to planned government. In contrast the Waterfall methodology is more in line with Socialism. Waterfall is far more plan centric it’s ridged, and less adaptable to change over time. Waterfall does what it can to make sure change is as painful and costly as possible. It’s no wonder at all why that methodology is for the most part dead.

Bringing Back In

Ok so I am not an economist and I really do not want to be tagged a right wing radical because of this post. But the point here is simple, frameworks should evolve organically overtime. Yes this means constant refactoring of your core code throughout the life of a project. When new patterns are introduced, your framework will change and code sweeps will need to happen. As your product grows so will the level of support your framework provides but on an as needed basis. Keeping in mind the framework should also limit developers to the current set of patterns that are supported by the current revision of your framework.

The benefit of framework limitation should not be underestimated. By limiting concepts allowed in your systems users start to learn and understand stereotypes. As a result new screens seem familiar to them, less support questions arise, and your application is usable unlike ITunes for the PC. The benefits are not only seen by users. Developers now have a common language when designing new screens. “This fits our Master Detail pattern”; “This fits our search pattern”. And if a scenario does not seem to fit existing patterns perhaps the introduction of something new is needed. And the cycle continues in a nice organic sort of way!

 

Enjoy

IDataErrorInfo and FluentValidation

I Got the chance to look at the FluentValidation.Net Framework this week. Overall its pretty spiffy! The API seems to handle most validation situations pretty well. Often times these things fall apart as soon as you run into a mildly complex situation such as dependent rule processing etc.  Using this for WPF and MVVM as it turns out is pretty simple. In this post I will show you a simple example of how to integrate FluentValidation.Net into your View Models, using the IDataErrorInfo interface and the databinding support provided by WPF.

Here is what I will cover in the post.

1. Create a View for the MainWindow
2. Create a ViewModel for the MainWindow
3. Create a Validator for the MainWindowViewModel
4. Setup Dependency Injection so ViewModels and Validators are both Injected as needed
5. Implement IDataErrorInfo so it routes calls our Validator implementation

If you do not have Unity and the FluentValidation dll’s, please learn how to use NuGet and go get it.

The MainWindow View

Very basic XAML here the intent is only to get the moving parts setup, not to win a beauty contest. Two things to notice here.

1. I have the binding set to update its source upon PropertyChanged this is not needed but I like instant feedback when possible.
2. In order to support IDataErrorInfo implementations you must set the dependency property ValidatesOnDataErrors to true.

<ribbon:RibbonWindow
    x:Class="MoreFluent.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:ribbon="clr-namespace:Microsoft.Windows.Controls.Ribbon;assembly=RibbonControlsLibrary"
    Title="MainWindow"
    x:Name="RibbonWindow"
    Width="640"
    Height="480">
    <Grid
        x:Name="LayoutRoot">
        <Grid.RowDefinitions>
            <RowDefinition
                Height="Auto" />
            <RowDefinition
                Height="*" />
        </Grid.RowDefinitions>
        <ribbon:Ribbon
            x:Name="Ribbon">
            <ribbon:Ribbon.ApplicationMenu>
                <ribbon:RibbonApplicationMenu
                    SmallImageSource="Images\SmallIcon.png">
                    <ribbon:RibbonApplicationMenuItem
                        Header="Hello _Ribbon"
                        x:Name="MenuItem1"
                        ImageSource="Images\LargeIcon.png" />
                </ribbon:RibbonApplicationMenu>
            </ribbon:Ribbon.ApplicationMenu>
            <ribbon:RibbonTab
                x:Name="HomeTab"
                Header="Home">
                <ribbon:RibbonGroup
                    x:Name="Group1"
                    Header="Group1">
                    <ribbon:RibbonButton
                        x:Name="Button1"
                        LargeImageSource="Images\LargeIcon.png"
                        Label="Button1" />
                    <ribbon:RibbonButton
                        x:Name="Button2"
                        SmallImageSource="Images\SmallIcon.png"
                        Label="Button2" />
                    <ribbon:RibbonButton
                        x:Name="Button3"
                        SmallImageSource="Images\SmallIcon.png"
                        Label="Button3" />
                    <ribbon:RibbonButton
                        x:Name="Button4"
                        SmallImageSource="Images\SmallIcon.png"
                        Label="Button4" />
                </ribbon:RibbonGroup>
            </ribbon:RibbonTab>
        </ribbon:Ribbon>
        <Grid
            Grid.Row="1"
            Margin="7,7,7,7">
            <StackPanel
                Orientation="Horizontal"
                Height="24"
                Width="250">
                <Label>Name</Label>
                <TextBox
                    Width="150"
                    Text="{Binding Path=Name, UpdateSourceTrigger=PropertyChanged, ValidatesOnDataErrors=True}"></TextBox>
            </StackPanel>
        </Grid>
    </Grid>
</ribbon:RibbonWindow>

Not So Fancy eh?

I suppose I should give you a screen shot. Not so pretty but good enough to get the point across!

And The Code Behind

And of course the CodeBehind. However minimal this is there are a few important things here to point out.

1. The Dependency Attribute. Unity uses this attribute to facility property dependency injection upon build up.
2. The setter for the ViewModel property wraps the DataContext making MainWindowViewModel the DataContext for the view.

using Microsoft.Practices.Unity;
using Microsoft.Windows.Controls.Ribbon;

namespace Validation
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : RibbonWindow
    {
        /// <summary>
        /// Gets or sets the view model.
        /// </summary>
        /// <value>The view model.</value>
        [Dependency]
        public MainWindowViewModel ViewModel
        {
            get { return (MainWindowViewModel)DataContext; }
            set { DataContext = value; }
        }

        /// <summary>
        /// Initializes a new instance of the <see cref="MainWindow"/> class.
        /// </summary>
        public MainWindow()
        {
            InitializeComponent();
        }
    }
}

The MainWindow ViewModel

The MainWindowViewModel exposes a single property and the implementation of the IDataErrorInfo interface. Notice again we are relying on Unity to inject the Validator. In real life the the IDataErrorInfo implementation would reside in some sort of base ViewModel class. For example purposes I will not be doing that here.

Notice the IDataErrorInfo indexer, this forwards the call to the Validator asking it to run any rules associated to the supplied property name. If any rules are broken the error messages are returned in a single string with line breaks between each error message. Additionally the Error property asks the Validator to Validate all of the rules on a given object and return the enumerated results, again including line breaks.

using System;
using System.ComponentModel;
using System.Linq;
using FluentValidation;
using Microsoft.Practices.Unity;

namespace MoreFluent
{
    public class MainWindowViewModel : IDataErrorInfo
    {
        #region Dependencies

        /// <summary>
        /// Gets or sets the validator.
        /// </summary>
        /// <value>The validator.</value>
        [Dependency]
        public AbstractValidator<MainWindowViewModel> Validator { get; set; }

        #endregion

        #region Properties

        /// <summary>
        /// Gets or sets the name.
        /// </summary>
        /// <value>The name.</value>
        public string Name { get; set; }

        #endregion

        #region IDataErrorInfo Members

        /// <summary>
        /// Gets an error message indicating what is wrong with this object.
        /// </summary>
        /// <value></value>
        /// <returns>An error message indicating what is wrong with this object. The default is an empty string ("").</returns>
        string IDataErrorInfo.Error
        {
            get
            {
                return Validator != null
                    ? string.Join(Environment.NewLine, Validator.Validate(this).Errors.Select(x => x.ErrorMessage).ToArray())
                    : string.Empty;
            }
        }

        /// <summary>
        /// Gets the <see cref="System.String"/> with the specified property name.
        /// </summary>
        /// <value></value>
        string IDataErrorInfo.this[string propertyName]
        {
            get
            {
                if (Validator != null)
                {
                    var results = Validator.Validate(this, propertyName);
                    if (results != null
                        && results.Errors.Count() > 0)
                    {
                        var errors = string.Join(Environment.NewLine, results.Errors.Select(x => x.ErrorMessage).ToArray());
                        return errors;
                    }
                }
                return string.Empty;
            }
        }

        #endregion
    }
}

The Validator

Of course this would be incomplete without the Validator so here it is! Just one simple rule.

namespace FluentValidation
{
    /// <summary>
    /// Validator for the MainWindowViewModel
    /// </summary>
    public class MainWindowViewModelValidator : AbstractValidator<MainWindowViewModel>
    {
        #region Constructor

        /// <summary>
        /// Initializes a new instance of the <see cref="MainWindowViewModelValidator"/> class.
        /// </summary>
        public MainWindowViewModelValidator()
        {
            RuleFor(x => x.Name).NotEmpty().WithMessage("Name is Required");
        }

        #endregion
    }
}

The Unity Setup

Setting up Unity is simple. Two things need to be done.

1. Remove the StartupUri from your App.xaml
2. Override OnStartup in your App.xaml.cs

The App.xaml

<Application x:Class="MoreFluent.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
		<!-- Resources scoped at the Application level should be defined here. -->

    </Application.Resources>
</Application>

The App.xaml.cs

using System.Windows;
using FluentValidation;
using Microsoft.Practices.Unity;

namespace MoreFluent
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);
            IUnityContainer container = new UnityContainer();
            container.RegisterType<AbstractValidator<MainWindowViewModel>, MainWindowViewModelValidator>();
            var mainWindow = container.Resolve<MainWindow>();
            mainWindow.Show();
        }
    }
}

Enjoy!

Team Dynamics

Team dynamics play a large part in the success or failure of a project. Often times they play a bigger role in an application making it successfully to production then the collective skill set of a team. I have had the opportunity to work on teams that have had both good and bad dynamics. The difference is night and day. A team that works well together and collaborates  is far more motivated, excited, and concerned with over all quality of the end product. Sadly the experiences I have had on teams with lousy dynamics are just the opposite. Team members will isolate themselves, quality will drop exponentially and team members stop caring because they are frustrated. This reduces the chances of creating a usable finished product to almost zero.

Something that I have found to be true in my tenure in the software development business is that personalities to a very large degree make or break a team dynamic.  In fact more important than the enumerated skill sets of a team are the personalities of the team members. Personality say a lot about a developers ability to work within the confines of a team and a methodology. Below I describe some of the personality types that I have seen on the various teams I have been on over time.

The Cherry Picker

The cherry picker hunts and pecks away at the requirement backlog, only working on requirements he/she finds interesting or easiest. What is worse, is that often times a Cherry Picker will break down a given requirement into several parts, again only working on the aspects he/she finds simple or interesting. Cherry Pickers never finish a requirement. They are done when they get board or confused caring very little about the state of the work  when they quit. This leads to the endless cycle of a requirement going from dev to test and back to dev. Cherry Pickers are bad.

The BA Developer

The BA Developer is one of the most frustrating personality types to work with. A BA Developer will find things he/she believes are shortcomings or missing requirement in a current system, decide without consulting other team members that it is important and do the work right now (99% of the time there is no defect or requirement to track the work against.) Because the BA Developer knows that the actions he/she is taking will be looked down upon by other team members no design discussion happens leading to fragile implementations of ‘features’ that may or may not be needed. Once the BA Developer completes his/her ‘enhancement’ the BA Developer will contact the team member he/she feels will be least appalled by the actions taken by the BA Developer. The BA Developer will then show the perceived weak team member the changes that were made. A BA Developer if confronted will claim things like ‘I have not checked anything in, I just wanted to see how it would look’ caring very little to the untracked wasted time that brings down the overall velocity of a sprint. The BA Developer is in my opinion one of the most toxic personality types to have on a team. Trumped only by the absolute worse The Sneaker.

The Sneaker

The Sneaker does not care about process, teamwork, standards, patterns, requirements or quality. You may be totally unaware that a Sneaker is among you until  you see first hand their handy work. The Sneaker is much like BA Developer with one critical infuriating difference. The Sneaker skips the showing, checks in the code and says nothing of it. When source control fingers The Sneaker, and you choose to confront the offender The Sneaker will say things like ‘well I mentioned it’, or ‘I talked to this person or that person’. You should fear above all other personality types The Sneaker.

The No Google-er

The No Google-er seems harmless at first, though somewhat annoying. When faced with a problem, their first instinct is to ask whoever is near by. Overtime if other developers allow this to continue, The No Google-er actually forgets about the vast resources available to us by simply asking a question to the handy text box on www.google.com. Often times they are in denial that a thing called the ‘internet’ exists. The No Google-er not only wastes other team members time he/she is responsible for a disproportionate percentage of defects reported, a problem that is greatly compounded around vacation season when their human search engines are out of town.

The Watcher

The Watcher is a strange personality type who’s motivation is as illusive as it is unpredictable. The single trait that all Watchers have in common however, is that they will hold others up to standard they themselves refuse to follow. A Watcher is the first to comment about other developers non-standard development practices while ignoring broken build notifications. Those who can do, those who can’t watch.

The Waiter

The Waiter is harmless enough, however they can be frustrating. Waiters are very common and come full of wonderful catch phrases like, ‘we are kind of low on work, do I did some online reading’, ‘I am waiting on ______’. Or the classic ‘I am ready to take on something new’. The Waiter is good in that they do not do to much work thus limiting the damage they can do. However they often times pass on work to more advanced team member out of sheer laziness stating that the work is above their skill level.

So there it is! The most common personality types I have run into in my career so far. I am sure you all have your own list, feel free to add them.

Lets Date!(An Approach)

Dates always seem to give me a headache when working with business apps. Trying to come up with framework level support for handling them is not always easy.  In this post I will outline an approach to dealing with dates that we are using with some success in my current project. Much praise to Matt Lindstrom for the actual implementation of what I am going to outline here.

ORM Mapping

In most databases columns defined as date types can be built to allow nulls. This makes sense when you consider the implications for reporting etc. In .Net the native DateTime object is a value type, thus it cannot represent null. To correct this inconsistency we leverage Nullable<DateTime> for all date properties. And to prevent all the nasty ‘HasValue’ checking in our ORM methods we use an extension method on Nullable<DateTime> as follows.

       /// <summary>
        /// Prepares for database.
        /// </summary>
        /// <param name="dateTime">The date time.</param>
        /// <param name="includeTimeStamp">if set to <c>true</c> [include time stamp].</param>
        /// <returns></returns>
        public static object PrepareForDatabase(this Nullable<DateTime> dateTime)
        {
            if (dateTime.HasValue)
            {
                return dateTime.Value;
            }
            return DBNull.Value;
        }

This method could be used the following way.

            /// <summary>
            /// Method used to build command
            /// </summary>
            /// <param name="database">Database to run command against</param>
            /// <returns>Fully loaded command object ready to execute</returns>
            public override DbCommand GetCommand(Database database)
            {
                DbCommand command = database.GetStoredProcCommand("MyInsertCommand");
                database.AddInParameter(command, "DATE_in", DbType.DateTime, SomeNullableDate.PrepareForDatabase());
                return command;
            }

Of course this code only covers the mapping to the data store some additional work is needed when saturating objects with data. Again to support this we added an extension method on the CSLA SafeDataReader. Here we also account for the MinDate assuming that it is the same as a null date.

        /// <summary>
        /// Gets the nullable date time.
        /// </summary>
        /// <param name="data">The data.</param>
        /// <param name="i">The i.</param>
        /// <returns></returns>
        public static DateTime? GetNullableDateTime(this SafeDataReader data, int i)
        {
            if (data.GetDateTime(i).Equals(DateTime.MinValue))
            {
                return null;
            }
            return data.GetDateTime(i);
        }

And in practice

        /// <summary>
        /// Method used for ORM mapping of CompRehabCase
        /// </summary>
        /// <param name="data">SafeDataReader</param>
        private void Populate(SafeDataReader data)
        {
            LoadProperty<Nullable<DateTime>>(SomeNullableDateTime, data.GetNullableDateTime(data.GetOrdinal("SOME_DATE")));
        }

And that all folks.

Nullable<DateTime>

Do You DoEvents?

Often times during the development of enterprise software requirements arise stating that specific operations need to be handled both synchronously and asynchronously. A perfect example of this is printing. Perhaps a user wishes to print a document and wait for confirmation of a successful print operation before moving on to the next step of their business process. Or perhaps the user wants to request a print operation for multiple documents in a fire and forget fashion. In one case we should provide some sort of user interface cue as to the status of the print operation and in the other we just fire and forget, while hoping everything works out.

Thinking Synchronously

So we have a WPF window with a Print Button we also have a label to indicate the status of the running print job.

Some XAML

<Window x:Class="WpfApplication2.Print"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="Print" Height="300" Width="300">
 <Grid>
 <StackPanel>
 <Button Command="{Binding Path=PrintCommand}">Print</Button>
 <Label Content="{Binding Path=PrintStatus}"/>
 </StackPanel>
 </Grid>
</Window>

Code Behind

using System.ComponentModel;
using System.Threading;
using System.Windows;

namespace WpfApplication2
{
    /// <summary>
    /// Interaction logic for Print.xaml
    /// </summary>
    public partial class Print : Window, INotifyPropertyChanged
    {
        #region Private Data Members

        private string mPrintStatus;

        #endregion

        #region Constructor

        /// <summary>
        /// Initializes a new instance of the <see cref="Print"/> class.
        /// </summary>
        public Print()
        {
            InitializeComponent();
            DataContext = this;
            PrintCommand = new RelayCommand(PrintExecuted);
            PrintStatus = "Ready";
        }

        #endregion

        #region Private Methods

        /// <summary>
        /// Prints the specified parameter.
        /// </summary>
        /// <param name="parameter">The parameter.</param>
        private void PrintExecuted(object parameter)
        {
            PrintStatus = "Print Executed";
            //Long Running Print Operatoin
            Thread.Sleep(1000);
            PrintStatus = "Print Completed";
        }

        #endregion

        #region Public Properties

        /// <summary>
        /// Gets or sets the print status.
        /// </summary>
        /// <value>The print status.</value>
        public string PrintStatus
        {
            get
            {
                return mPrintStatus;
            }
            private set
            {
                mPrintStatus = value;

                var handler = PropertyChanged;
                if (handler != null)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("PrintStatus"));
                }
            }
        }

        /// <summary>
        /// Gets or sets the print command.
        /// </summary>
        /// <value>The print command.</value>
        public RelayCommand PrintCommand
        {
            get;
            private set;
        }

        #endregion

        #region INotifyPropertyChanged Members

        /// <summary>
        /// Occurs when a property value changes.
        /// </summary>
        public event PropertyChangedEventHandler PropertyChanged;

        #endregion
    }
}

Looking at the code here you can see that the intended behavior is as follows.

1. User Clicks Print Button
2. PrintCommand is executed
3. A label used to show the print status is updated from ‘Ready’ to ‘Print Executed’
4. The long running Thread.Sleep is called simulating a synchronous print operation
5. Once complete the status is again changed to ‘Print Completed’

This sequence of events does actually happen, the problem however is that it all happens within the execution scope of the  PrintExecuted method. Since this method is blocking until completed the user never sees the nice status updates we provide.

Before Click

When the window is loaded the status is set to ‘Ready’ as seen in the image on the left. Once the print button is clicked we want to change the status to ‘Print Executed’ and finally when the PrintCommand is complete to ‘Print Complete’. However since the updates to the status all happen while the UI thread is blocking, the status of ‘Print Executed’ never makes it to the user. Instead the status will transition from ‘Ready’ directly to ‘Print Completed’  upon command completion. This presents a pretty serious issue if you need to give the user meaningful feedback about what is going on. On interesting way to get around this is to use DoEvents.

Do a What?

If you came to the wonderful world of WPF DoEvents was something new to you. In fact when I first presented this problem to a colleague with a strong Win Forms background he was quick to mention this. So what is it?

Take a look

To make a long story short DoEvents allows you to interrupt current event processing in order to process waiting events in the message pumps message queue. The good/bad news depending on your view of such things, is that if you need to replicated DoEvents in WPF you can. Because  WPF and WinForms both leverage the User32 message pump. the solution ends up to be very simple Lets take a look and what our PrintExecuted method might look like.

#region Private Methods

        /// <summary>
        /// Prints the specified parameter.
        /// </summary>
        /// <param name="parameter">The parameter.</param>
        private void PrintExecuted(object parameter)
        {
            PrintStatus = "Print Executed";
            Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, new ThreadStart(delegate { }));
            Thread.Sleep(1000);
            PrintStatus = "Print Completed";
        }

        #endregion

This approach give us the desired behavior of all of the status updates being presented to the user. Why this may not be a great illustration of proper use of an admitted hack. It is always good to have another tool in your toolbox.

Enjoy!

AcroRd32.exe I hate you (well kinda).

The WebBrowser control is a pretty cool thing. You can use it to host many different document types allowing the user to work with a specific type of document in its most common user interface, at the same time the WebBrowser control frees the developer from writing much of the interop code that would be needed otherwise. And that is always a plus!

However as with any kind of inter-operation between disparate technologies you run into hiccups. A good example of this is what happens when you use the WebBrowser control as a container for AcroRd32.exe to view PDF documents. To understand this ‘hiccup’ we can look to Adobe knowledge base for some guidance.

Adobe Acrobat and Adobe Reader are designed to continue running for a few minutes after you close the browser window in which you viewed PDF files.

If you are interested in a more detailed description take take a gander at this KB.

Adobes ‘Design’ decisions present several challenges when working with PDF documents in a WebBrowser control. The following use case illustrates it best.

1. User searches for a document.
2. User views document (Presumably in a WebBrowser control).
3. User closes document.
4. User attempts to delete the document after closing it.

A issue arises when the user attempts to delete the document upon closing it. Because AcroRd32.exe will hang on to your precious PDF document for ‘few minutes’ upon closure any attempt to delete said document will result in the following error.

The process cannot access the file ‘YourPdf.pdf’ because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

This is a problem. Adobe is holding our document hostage. This aggression will not stand man! Outside of killing the AcroRd32 process (an option that results in all open PDF documents being closed) we have very little recourse against Adobe’s design decision. Getting around this little hiccup ends up being pretty simple and involves always loading a ‘working’ version of the file. Or simply stated every document you load with the WebBrowser control should be a copy of actual document you want to work with. So how do we manage that copy? I suppose there are several ways to do this. However one I found particularly interesting was to use the use the TempFileCollection in the System.CodeDom.Compiler namespace. This was interesting to me for one major reason,  when adding a file to this collection you can supply a flag to indicated that it should be removed upon garbage collection. This is perfect when you truly want a working file and you want it to be gone when you are done with it. Lets take a look at some code that might do this.

<Window x:Class="PDFSample.Window1"
 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Title="Window1">
 <Grid>
 <Grid.ColumnDefinitions>
 <ColumnDefinition />
 </Grid.ColumnDefinitions>
 <WebBrowser x:Name="wbPdfViewer"
 Grid.Column="0" />
 </Grid>

</Window>

and the code behind….

using System;
using System.CodeDom.Compiler;
using System.Windows;

namespace PDFSample
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        #region Private Data Members

        private readonly TempFileCollection mTempFile = new TempFileCollection();

        #endregion

        #region Constructor

        /// <summary>
        /// Initializes a new instance of the <see cref="Window1"/> class.
        /// </summary>
        public Window1()
        {
            InitializeComponent();
            wbPdfViewer.Source = new Uri(GetWorkingDocumentPath());
        }

        #endregion

        /// <summary>
        /// Gets the working document path.
        /// </summary>
        /// <returns></returns>
        private string GetWorkingDocumentPath()
        {
            string workingFile = string.Concat(System.IO.Path.GetTempPath(), "MySampleApp_", Guid.NewGuid(),".pdf");
            System.IO.File.Copy(@"C:\Unity-v1p2-October08.pdf", workingFile);
            mTempFile.AddFile(workingFile, false);
            return workingFile;
        }
    }
}

Enjoy!

I Hate Trees

So not really. I don’t particularly mind trees. Tree controls on the other hand I hate. Take for example a simple requirement of launching a new window each time a tree item is selected. Simple right? Well not in WPF. Lets look at a quick example.

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <TreeView>
            <TreeViewItem Header="Root">
                <TreeViewItem Header="Parent" >
                    <TreeViewItem Header="Child" Selected="ChildTreeViewItem_Selected"></TreeViewItem>
                </TreeViewItem>
            </TreeViewItem>
        </TreeView>
    </Grid>
</Window>

Pile!

The idea here is simple. I want to click on the TreeViewItem labeled ‘child’ and launch a new Window when the its Selected event is raised.

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void ChildTreeViewItem_Selected(object sender, RoutedEventArgs e)
        {
            new Window().Show();
        }
    }
}

Ok so maybe that is not all want. Along with a new window launching, I want it to have focus, and I want the TreeViewItem clicked to turn gray indicating the selection made. Sadly however, this is not what I get. Instead the window is launched *not to bad*, however the new window does not have focus after it is activated *who needs focus*. If that is not bad enough adding insult to injury the TreeViewControl in what I can only imagine is a last ditch effort to handle focus raises a second Selection event on the the TreeViewItem labeled Parent. This *bonus* event sets focus back to the TreeViewControl, showing the incorrect TreeViewItem selected. Like so.

HATE YOU

Humm this image is not so clear how is this.

Pile

In the image above you will see that the ‘Parent’ node is selected. That would be fine if that is what I clicked!

Okay okay rant done. How to fix this? Well I spent a day on this sadly, hence the blog posting. Turns out in order to get this to work you need to use the dispatcher. I am not sure why but when I use a simple Action delegate to launch the window using the Dispatcher it all works just fine. Here is the code.

namespace WpfApplication1
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }

        private void ChildTreeViewItem_Selected(object sender, RoutedEventArgs e)
        {
            Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() => new Window().Show()));
        }
    }
}

Anyone care to comment on why this works? Well at least it does!

Enjoy!

A Better Sandwich!

When considering topics for blog posts more often then not I filter out ideas based on their technical merit. I try my best to offer solutions to problems that I face everyday as a software developer in an attempt to repay the many others who’s blog postings have helped me. This post however does not fall into that category. So feel free to ignore it.

In a recent dinner with my wife and her parents. I retold a story that my wife has heard many times before. This particular time however, I managed to make some correlations to software development that had not previously occurred to me. So before I go any further let me retell the story…. Again…

In the beginning…. Wait wrong story.

When I was in high school I was dating a girl who in all accounts was much smarter then I was. However since I was a rocking guitar player and all around rebel she found my charms irresistible.

*The statement above is a complete embellishment except for the fact that she was indeed much smarter then I am*

One night while the two of us sat in my parents kitchen, I decided to take full advantage of the refrigerator filled with all of the parental subsidized food you could imagine, and make us some sandwiches. I grabbed some lunch meat, lettuce, tomatoes, mustard and all the other standard sandwich fixings available. I reached for the bread box to grab the bread, and the sandwich making commenced.

First up my sandwich (because I am selfish). I slapped down two slices of bread and started to add the fixings. On one slice went the meat, and on the other slice all of the fixings, salad, mustard, onions etc. Once all of the fixings were in place I grabbed each fully loaded slice and tried my best to marry the two without dumping the fixings all over. I managed to get the sandwich together like I had with all sandwiches before. After all I was not at all new to the art of sandwich making with free ingredients. I took a look over at my girlfriend expecting a look of awe as she basked in my artistry. Instead I got a look of utter confusion mixed in with a little disgust. She said, “Really? That is how you make a sandwich?” This was the beginning of the end for use as a couple. She then continued to tell my how much easier it would have been if I put all of the fixings on one slice of bread, and simply placed the second slice on top.

Her words flipped my world upside down. I could not believe what she was saying! It was a perfect solution. A perfect solution to a problem I never thought existed! I then proceeded to make her the most efficiently crafted sandwich I had ever made. It was a work of art that would bring the likes of Picasso to tears.

And that is the story. My story of a better sandwich! So why blog about it?

Well at that moment when my girlfriend pointed out the problems in my process I realized that had she not done so, I would have continued making sandwiches that way. Who knows how long or how many sandwiches would have fallen victim to my intellectual laziness. The reason this horrible process would have continued is because despite its short comings it did in fact work. At the end of this process I could always partake in some tasty sandwich goodness.

The point here is simple. You can go years and years doing what you do the way you always have. The results after all in this case were just fine. The same is true in software development. We can follow all of the patterns we have always followed. We use all of the best practices we have spent so long learning and mastering over and over again. And as long as we do that and nothing major changes we can turn our brains off and churn out application after application, object after object, and pattern after pattern. And all along never even considering that there may be a much better way to make a sandwich. And if we are not looking for ways to make our sandwiches better, what the hell is the point!

Enjoy!