Setting the focus in the UI is tricky when using MVVM because the ViewModel doesn’t “know” about the View, and certainly doesn’t have the ability to make calls like “myView.myControl.Focus().”

In the WPF application I am building with Caliburn Micro I had the need to control the focus from the ViewModel in a number of places.  For instance, on my login page, if the user entered incorrect credentials and click the “Login” button, I needed the ability to set the focus back to the TextBox for the user name. 
Additionally when the login page first gets displayed, I needed the focus to be initially set to the user name TextBox to minimize unnecessary mouse clicks and tabbing for the user. 

All of the above issues are demonstrated in the attached sample solution.  (Please note that the sample solution is going against a one-off version of the Caliburn Micro binaries–I describe the minor changes that I made to the Caliburn source below).

 How to Set the Focus From the ViewModel

 So, how can the ViewModel set the focus in the View?  Very simply.  If there is a LoginView with this XAML:

             <TextBox x:Name=Username/>

…and a LoginViewModel with this property:

            public string Username { get; set;}

…then simply create a new property of type bool that follows the naming convention IsMyPropertyNameFocused.  So for the current example you would add

             public bool IsUsernameFocused { get; set;}

If the same LoginViewModel then has a LogIn() method that gets invoked when the user clicks a button named Login, it then has the ability to control when the UIElement bound to the Username property receives focus like so:

 public void LogIn()
{
            //just assume login fails for simplicity
            DisplaySomeErrorMessageToUser();
            IsUsernameFocused = true;
            NotifyOfPropertyChange(() => IsUsernameFocused);
}

 I have tested this approach with WPF and it should also work with Silverlight since this “MVVM focus by convention” approach works via attached behaviors.  I have no idea whether this will work with WP7 or not.

 Changes to Caliburn Micro Source Code

I can’t take the credit for inventing the ideas I use to accomplish this.  All I’ve done is take the clever code of others that I’ve found online and incorporate them into Caliburn Micro’s “Convention Over Configuration” approach to make this sort of thing easier to do.  The central idea of using a “FocusExtension” attached behavior to set a control’s focus from a ViewModel I got from StackOverflow user “Anvaka” here.

I did make some minor code changes to Anvaka’s approach, namely setting the focus on the Dispatcher with a Background priority so that it will still get set even if the control isn’t loaded when the ViewModel tries to set it and also flipping the focus attached property back to false immediately after it gets set.

Here are the changes I made:

1. Add the FocusExtension class in the Caliburn Micro Silverlight project (with a few preprocessor directives so it will work for WPF also) and then in the Caliburn Micro WPF project pick Add Existing Item and select FocusExtension and click the dropdown arrow on the Add button and choose “Add as Link”.

 //this great implementation taken from Anvaka’s answer on StackOverflow here:
 //http://stackoverflow.com/questions/1356045/set-focus-on-textbox-in-wpf-from-view-model-c-wpf/1356781#1356781
    public static class FocusExtension
    {
        public static bool GetIsFocused(DependencyObject obj)
        {
            return (bool)obj.GetValue(IsFocusedProperty);
        }

         public static void SetIsFocused(DependencyObject obj, bool value)
        {
            obj.SetValue(IsFocusedProperty, value);
        }

#if SILVERLIGHT
        public static readonly DependencyProperty IsFocusedProperty =
                DependencyProperty.RegisterAttached(
                 “IsFocused”, typeof(bool), typeof(FocusExtension),
                new PropertyMetadata(false, OnIsFocusedPropertyChanged));
#else
        public static readonly DependencyProperty IsFocusedProperty =
         DependencyProperty.RegisterAttached(
          “IsFocused”, typeof(bool),  typeof(FocusExtension),
          new UIPropertyMetadata(false, OnIsFocusedPropertyChanged));
#endif
        private static void OnIsFocusedPropertyChanged(DependencyObject d,
                DependencyPropertyChangedEventArgs e)
        {
#if SILVERLIGHT
            var uie = (Control)d;
#else
            var uie = (UIElement)d;
#endif
            if ((bool)e.NewValue)
            {
                uie.Dispatcher.BeginInvoke(new System.Action(delegate
                {
                    uie.Focus(); // Don’t care about false values.
#if !SILVERLIGHT
                    Keyboard.Focus(uie);
#endif
                    //need to switch it back to false right away so we can detect future change notifications
                    //back to true
                    SetIsFocused(d, false);
#if !SILVERLIGHT
                }), DispatcherPriority.Background, null);
#else
                }), null); //this SHOULD work in Silverlight because I understand that the only DispatcherPriority is “Background”
#endif
            }
        }
    }

2.  Add the CheckForFocusProperty method in ViewModelBinder

private static void CheckForFocusProperty(string focusPropertyName, PropertyInfo[] properties, FrameworkElement foundControl)
        {
            if (properties.FirstOrDefault(prop => prop.Name.Equals(focusPropertyName, StringComparison.InvariantCultureIgnoreCase)) != null)
            {
                ViewModelBinder.SetBindingOnFocusExtensionAttachedBehavior(focusPropertyName, foundControl);
            }
        }

3. Add the new SetBindingOnFocusExtensionAttachedBehavior method in the ViewModelBinder class in the Caliburn Micro Silverlight project

private static void SetBindingOnFocusExtensionAttachedBehavior(string bindingPath, FrameworkElement foundControl)
{
            Binding b = new Binding(bindingPath);
            b.Mode = BindingMode.TwoWay;
            BindingOperations.SetBinding(foundControl, FocusExtension.IsFocusedProperty, b);
}

4. Call the CheckForFocusProperty method from the BindProperties and BindActions methods in ViewModelBinder.

 That’s it.  Now if you build Caliburn Micro and reference the appropriate Caliburn Micro binaries in your WPF or Silverlight project you can start adding boolean properties with the IsMyPropertyNameFocused convention and then set them to true and raise a property change notification to set focus in the view.

Other Useful Things Shown in the Sample Solution

Have a look at the attached sample solution to see this kind of functionality in action.In addition to setting focus from the view model there are a couple of other helpful things for MVVM developers that are illustrated:

1. using the WPF PasswordBox with MVVM via PasswordBoxHelper attached behavior (not my idea, I got this from Samuel Jack here)–note that is only necessary for the WPF PasswordBox, it is not a problem in SL

2. selecting all the Text in a TextBox when it receives focus via attached behavior (not my idea, I got this from Sergey Aldoukhov here)

The Code

Here’s the source for both the same project and the modified version of Caliburn.Micro. (I suck at blogging so right click the links and Save Target As…then rename them from .doc to .zip).
Caliburn.Micro.FocusExample
Caliburn.Micro.FocusChanges

Enjoy,

Josh

Next, I created a converter which took that integer value and converted it into an appropriate string value to display time in minutes:seconds format, or hours:minutes, depending on how long they were playing the game.  Then in a TextBlock in my View I had a binding to the ElapsedSeconds property on the ViewModel and used my custom converter.

This worked, and I was reasonably happy with it–I even unit tested my converter and felt good about it. 

But in the back of my mind I was still batting around the ideas about using ViewModels instead of converters.  At first I disagreed with that approach. After all, why should the ViewModel care about the display format of their values, which seems to be a purely UI concern?  Furthermore I had unit test coverage of my Converter so I could test my formatting logic.  It didn’t make sense. 

Then, for the heck of it, I decided to try it that way.  I kept my ElapsedSeconds property on the ViewModel and added a property called ElapsedTime of type string.  To keep change notification working for Bindings to this property I raise property changed in the setter of ElapsedSeconds which is the property that the ViewModel uses internally. 

The best part is that the functionality to convert from an integer of seconds to a formatted string of “time” is now in an extenstion method I wrote for type Int32. The getter for ElapsedTime simply calls that extension method on the member variable which holds the number of elapsed seconds.  The extension method can of course be fully unit tested just like the converter could, but it has requires less code both in the method itself andthe unit test class, because unlike a converter it is typesafe. 

So, overall I think I like it better.  There’s  less “ceremony code” than there used to be in the extension method than in the converter (Int32.TryParse() calls with the value passed into the converter, and returning Binding.DoNothing for bogus inputs).  I no longer have to have unit tests that passed in bogus values to the converter to make sure it would react appropriately–the unit tests can focus on only testing valid cases now since the extension method can only be called on Ints. That alone saved me quite a few lines of code.

Of course there is nothing preventing UI layer developers from building and using their own value converters in their bindings in XAML.  The way I see is that the ViewModel offers up the “raw” format (seconds as integers) as well as a fancy format that will work in many UIs so that many UI developers wouldn’t have to write their own converter.

I still think there may be uses for converters. But I’m hard-pressed to think of any in which you have the ability to modify the ViewModel source.

At first I was uncomfortable with the idea of  UI formatting or Focus change events (see Josh Smith’s blog) ocurring in the ViewModel because it seems to not be separating concerns appropriately.  But I think the key is to remember that the ViewModel really is modelling a view.

Anyhow, that’s what is on my mind tonight.

Because the API was poorly designed my “Builder” class needed to iterate and do some complex filtering and conditional logic on 4 different collections off of R.  I carefully designed my Builder to follow the Single Responsibility principle, and thus while the data it returned would feed a UI, it had no UI concerns of any kind within it.  It would be a great bit of code to unit test, especially since it was brand new.

Unfortunately the R class made this impossible.  It implemented no interfaces.  It had 5 constructors and the one with the fewest arguments had 24 different parameters, many  of which were other complex types.  Incidentally only 1 of the many complex types implemented an interface, the others were just like the R class and took in many othe subobjects in their constructor params.  This made unit test setup a downright impossibility. 

Some of the objects could literally only be newed up with data from the database. I tried subclassing R with “TestableR” so I could pass that into my Builder, but R had no default constructor so my TestableR class would’ve been required to invoke one of R’s constructors which left me right back where I started.

Why,  you may ask, did I not extract an interface for R, which would be a non-breaking change? Because in the organization who owns the code this is (for reasons unknown to me) and controversial and politically charged issue.  While that goes unresolved, most new code added to the system, no matter how well designed, is effectively untestable. Put this down as a Daily WTF.

This means that as someone who tries to stay in decent shape, I have to go the gym and run mindlessly on a treadmill rather than the great outdoors.  For those that use treadmills, you’ll know that they usually have a “stop” button on the main front panel–the same panel where you typically enter your speed and incline.  Some treadmills also have a special failsafe device that has a cord that is attached to you or your clothing–the idea being that if you fall off the treadmill it will trip the failsafe mechanism and instantly stop moving.  The photo here is typical of a treadmill and it’s red stop button.

The other day the gym was busy and I had to use an older cheaper treadmill in the back row, far from the TVs at the front.  It had a unique “feature”. 

It’s “Stop” button was located in the center on the left handrailing of the treadmill.  It’s a non-standard design.  Being non-standard in and of itself isn’t bad–especially if it improves on the design flaws of the standard design.  However, this design has a uniquely annoying design flaw.  See if you can think of it on your own before highlighting the blank area below to see the answer:

A runner can easily bump the stop button inadvertantly if they lower their arms a bit while running.  This happened to me twice, and I didn’t appreciate having my run stopped just as I was getting into the rhythm.  In fact, I cannot think of any advantage at all–from a usability perspective–to having the button on the railing. Maybe it’s cheaper or easier to manufacture.

How does this apply to software design?  A developer can certainly feel free to innovate and think of “out of the box” solutions (after all, if we didn’t try news things we’d all still be doing FORTRAN)–but they need to be sure that they aren’t being different just for the sake of originality–and it must absolutely be USABLE.  There needs to be a meaningful advantage to implementing an off-beat solution.

• Start with 1 for a straight path through the routine.
• Add 1 for each of the following keywords or their equivalent: if, while, repeat, for, and, or.
• Add 1 for each case in a switch statement.

For me, the most interesting thing about cyclomatic complexity is that it can point you to areas in your app that need to be refactored–high cyclomatic complexity numbers indicate methods and classes that need to be extracted.  The higher the complexity, the harder to change the code later and the harder to find and fix bugs in the code.

Raymond Lewallen made a blog post about his personal thresholds for cyclomatic complexity and I agree with him.  Jeff Atwood also had a great blog post about “Flattening Arrow Code” to reduce cyclomatic complexity.  After reading these posts, I was inspired to see how my Micro-ISV app is doing in this area.

So I ran Reflector with the CodeMetrics Add-In against my assemblies.  The results were interesting—most of my classes were below 10, quite a few were in the teens and low 20s (good enough for me for the time being since all my code has unit tests) and 2 classes had very high complexity.  Overall, I was pretty happy with this, because most of the code is pretty well refactored.

One class had a cyclomatic complexity of 36.  This class is the most frequently-used class in the API I’m building and has lots of different pieces of information as it is basically an html node.  Thus it stores information about node name, type, attributes, inner text, parent node, additional nodes contained within it, etc.  It also knows how to run run XPath queries against itself.  There aren’t too many actual conditionals or loops in it, and it doesn’t contain any nested if’s/whiles, etc–it just has alot of methods.  I’ll have to see if I can extract some of them to another class–I want to make sure my class follows the Single Responsibility Principle.

The other class with a high cyclomatic complexity number of 43! Ugh.  This didn’t surprise me however.  It is my implementation of Microsoft’s XPathNavigator class, which is where the real processing of XPath queries happens.  It’s an internal class as consumers of my API don’t need to know about it’s existence.  Unfortunately there’s just a TON of methods in it–and again, none of them have deeply nested conditionals, but most of them have at least 1-3 conditionals.  The abstract System.Xml.XPath.XPathNavigator class has lots of abstract methods defined on it so there’s not much I can do about that.  I could factor out some of what happens inside these methods into other classes.  I’ll have to think about whether or not that is worth pursuing.  Any reader thoughts?

Because my Navigator implementation is internal, I chose not to write any unit tests against it even though I could have–I typically mark my unit test project as a friend assembly so I can test internal methods if I need to.  In this case though, I have quite a few unit tests (and some separate system tests) that verify that XPath queries are returning the expected results.

However, I have definitely seen the over-use of patterns or the applying of patterns too soon.  This tends to create un-needed flexibility and un-needed loose coupling.  Basically code that won’t change alot is abstracted and made very easy to change.   Clearly work is wasted when this happens.

My take is that often patterns are most useful as a language for communicating a design with other developers.  Sure, sometimes you can identify the need for a design pattern just from requirements rather than from code, but often you guess wrong if you try to do that.

My preferred approach is interative Test-Driven Development.  Along the way I incrementally follow good object-oriented design principles ensuring that I don’t introduce abstraction until I need it.  This means interfaces and abstract classes usually aren’t created until a refactoring step.  Oftentimes while doing this I will find that by virtue of following these OO concepts I have produced a solution that is a design pattern.

 What basic OO principles am I referring to?

1.   The DRY (Don’t Repeat Yourself) Principle 

2.  The Open/Closed Principle

3.  The Dependency Inversion Principle

4.  The Law of Demeter

5.  Favor Composition Over Inheritance

6.  Separation of Concerns

7.  Single Responsibility Principle

This basic approach to development, unit-testing, and design that I use is my interpretation of what the author of Refactoring to Patterns was saying.

I plan on doing a series of additional posts talking about each of the above principles in turn.

One of their more interesting chapters talks about Software Entropy and Broken Window Theory.  They basically liken a codebase to an inner city building.  If a window is broken and left unfixed, people stop caring and before you know it there is trash everywhere, graffiti, grass growing through cracks in the sidewalk and you have a great deal of disorder (AKA entropy). 

The same is true of code.  Perhaps you just put in some crappy hard-to-read code just to “get it done” for a looming deadline.  Perhaps you have some code that “works” even though you don’t know how or why it works.  These are broken windows.  They need to be fixed ASAP, or at least marked as broken so they can be fixed as quickly as possible.  Failure to fix these broken windows has a big psychological impact—I guarantee that before you know it you’ll be thinking “this code is crap already, I’ll just tack on another quick and dirty solution.”

Before you know it, you have code entropy–code so unreadable, convoluted and mysterious that you can longer change it without breaking the system altogether.  Then the system dies a slow death or has to be rewritten from scratch.  I know I’ve been there, which is why I’ve learned to fix all broken windows.

 That said, you’ve still got to balance the principle of fixing windows ASAP with the idea the “perfect is the enemy of good”, which is another principle the Pragmatic Progammers address (thought they don’t have that excerpt from the book online). 

The Pragamtic Progammer should be required reading for all Computer Science students–as you can see it covers psychological issues related to progamming in addition to more “hard” topics like orthogonality, cohesion, coupling, automation, planning, etc.

 That said, I think that the not-terribly-Agile practice of Rapid Prototyping it too often overlooked. In my current app development I did a Rapid Prototype that is proving to be very useful–my only regret is that I didn’t do it sooner as it could have saved me some serious work. 

For instance, several times lately I’ve been doing some UI code with the Model-View-Presenter pattern.  I start by test driving my Presenter and mocking out of the View–deferring presentation layer decision until later.  Unfortunately several times I have not considered the necessary things that the View will need in order to do some presentation specific things–such as highlighting specific strings or nodes.

I then stepped back and did some rapid prototyping around this screen (yielding the wrapped TreeView solution spelled out in my previous post) and found it to be very helpful.  Armed with new knowledge about what my View would really need to do its job I was able to continue to test drive my actualy production code and make it work nice and pretty cleanly. 

 My first regret was not starting my rapid prototype sooner as it would’ve kept me from wasting time on throwaway work the first time around.  My second regret was not adding one final bit of functionality to my rapid prototype which is now causing me some similar problems in my production code.

If any readers have any thoughts about when to use Rapid Prototyping and how best to combine it with Agile development processes, I’d be interested to hear it.  For myself, I’m beginning to realize that it can be really helpful with MVP UI development.  I guess my rapid prototyping is on a very small scale—mostly just a screen-by-screen basis rather than building a complete prototyped system.

For those interested in learning more about the Model-View Presenter design pattern in .NET and why you’d want to use it check out Jeremy Miller’s excellent series on it at CodeBetter.com

1.  No MultiSelect functionality built in.

My app requires this kind of functionality, and while it’s certainly possible to add it, I’d rather not have to.  Seems like it should come with it.  Expecially if you consider the TreeViews used in Windows Explorer which allow you to select multiple folder nodes.  Am I asking for too much here?

2.  No ability to populate the TreeView by binding directly to an XML Document.

I know that the web version of the TreeView control supports that kind of functionality out of the box.  Instead I have to recurse through by object graph and build up an object graph of TreeNodes inside of TreeNodeCollections that mirrors my object graph structure.  Not a huge deal I guess.

3.  Why, oh why did Microsoft make the constructor of TreeNodeCollection internal rather than public?

Quick primer on the way the TreeView works.  The TreeView control has a TreeNodeCollection which contains TreeNodes.  Each TreeNode can also have it’s own TreeNodeCollection.  In my app, I needed a way to associate each TreeNode with an XMLNode.  The idea being that I wanted to be able to have the user input an XPath query and then have the TreeView select the node that the query returns. 

Rather than come up with some lame way to map back and forth between TreeNodes and XmlNodes I decided to extend the TreeView control.  So now I have XmlTreeView and XmlTreeNodeCollection and XmlTreeNode.  They inherit from the out of the box objects and in fact the only real new functionality is that XmlTreeNode now has a public XmlNode property.  That allows me to recurse through all the XmlTreeNodes in the XmlTreeView until I find a node that contains the XmlNode that was returned by the XPath query.  Then I just say something like XmlTreeView.SelectedNode = currentXmlTreeNode. 

 XmlTreeNodeCollection and XmlTreeNode both wrap their corresponding base objects and the XmlTreeNodeCollection keeps itself in synch with it’s hidden TreeNode collection so that I had to reimplement as little of the TreeNode functionality as possible so that the wrapped TreeView control could still act upon the objects it expects in order to manage its state and such.

 Pretty simple right?  For whatever reason though, my task in extending those objects was made more difficult and less unit testable by the fact that the only constructor for TreeNodeCollection is internal.  This meant that I either had to do what Microsoft did–when a TreeNode is created it then calls the internal contructor on TreeNodeCollection (same goes for the creation of a TreeView)—or I could make my XmlTreeNodeCollection constructor public but then have it create a temporary TreeNode just for the purpose of initializing it’s wrapped TreeNodeCollection or I had to use reflection to call it’s internal constructor.

I ultimately went with option 1–having an XmlTreeNodeCollection with an internal constructor.  It means that in my unit test class I have to create a throwaway XmlTreeNode and grab it’s Nodes collection in order to initialize my XmlTreeNodeCollection.  Not thrilled with it, but it works.

I’m totally in favor of OOP–which means I believe in encapsulation and information hiding.  However I found this design choice to be annoying.  I’ve made my share of internal classes and methods, and even internal constructors—but this really cramped my style.

 Let me know what you think about this.  Maybe that’s what I get for trying to use their objects in a  way they never intended.