I recently ran into a few problems with RoutedCommands in a ContextMenu I was adding to an application.  The problem was that when the ContextMenu was opened it wasn’t always finding the command bindings that I had in the parent Window (it would sometimes) and so the MenuItem was disabled.  After searching the web for some answers I found a few people that had also noticed this problem and they had a proposed work around.  You can find the work around here.  However the work around provided didn’t fit well with how I was setting up the ContextMenu so I decided to dig a little deeper.  After about 8 hours I found the reason and a solution to the problem that is far easier (at least for me) to put in place.

Before we go too far though I’ll provide some code so that you can replicate the issue for your self.  If you start with a blank WPF application project called RoutedCommandInContextMenu then you can simply add the following code to the listed files.

Add to Window1.xaml

<Window x:Class="RoutedCommandInContextMenu.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:RoutedCommandInContextMenu"
        Title="Window1"
        Height="300"
        Width="300">
    <ScrollViewer>
        <TextBlock Text="fooooobaaaaaar">        
            <TextBlock.ContextMenu>            
                <ContextMenu>                
                    <MenuItem Header="Foo"
                              Command="{x:Static local:MyCommands.FooBar}" />            
                </ContextMenu>        
            </TextBlock.ContextMenu>
        </TextBlock>
    </ScrollViewer>
</Window>

Add to Window1.cs

    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
            CommandBindings.Add(new CommandBinding(MyCommands.FooBar, FooExecuted, CanFooExecute));
        }

        public void FooExecuted(object sender, ExecutedRoutedEventArgs e)
        {
            MessageBox.Show("Foo!");
        }

        public void CanFooExecute(object sender, CanExecuteRoutedEventArgs e)
        {
            e.CanExecute = true;
        }
    }

    public static class MyCommands 
    { 
        public static RoutedCommand FooBar = new RoutedCommand();     
    }

If you then run this application and right click (without doing anything else first) you will see that the “Foo” menu item is disabled in the context menu.  You will also note that if you left click the non border area of the window and then right click again the “Foo” menu item is enabled.

When I first noticed this behaviour I thought that perhaps the MenuItem was simply not calling the CanExecute method of the command.  So I made a simple WrappedCommand class that implemented ICommand and used that as the command instead.  I was then able to put a break in the can execute method of my wrapped command and see that it was indeed being called.  I could also see that the underlying routed command was returning false for its CanExecute even though the Window’s command binding was never being called.  Clearly there is something going on with the routing of the command.

ContextMenus are implemented as a separate window which is managed by the Popup class.  Because of this they have a different Visual Tree.  Their Logical Tree is also separate from the Window they were launched from.  There are one or two situations where it looks like the Popup might report itself to be a child of the launching Window, but it doesn’t in the case of our ContextMenu (even when it is working in our example).

It turns out that in when a UIElement is determining if a routed command can execute or not it uses an internal method on the CommandManager class called OnCanExecute. In here we can see (with enough analasis) that the method searches for a command binding within the focus scope of the sender (the element that raised the event), then if it can’t find one it will transfer the event to the parent focus scope (assuming there is one) to see if it has any CommandBindings registered.  This is how the routed command execution travels from the ContextMenu to the Window when things are working.  The thing is that it will start routing the event in the parent scope from whatever has the logical focus in that scope, this is where our problem lies.  Until we click the window (actually the ScrollViewer to be precise) the current logical focus is null, which means that the CommandManager doesn’t know where to start routing the event in the parent focus scope so it doesn’t transfer the event.  Once we click the ScrollViewer the logical focus scope is set to the ScrollViewer so the CommandManager transfers execution of the routed event to the scroll viewer which then finds the Window’s command bindings and everything is dandy.

To fix this issue you can simply add a call to Focus() in the Window’s constructor like so:

    public Window1()
    {
        InitializeComponent();
        CommandBindings.Add(new CommandBinding(MyCommands.FooBar, FooExecuted, CanFooExecute));
        Focus();
        // Alternativly you could use
        // SetValue(FocusManager.FocusedElementProperty, this);
        // Another alternative is to use the following on the Window element in XAML
        // FocusManager.FocusedElement="{Binding RelativeSource={x:Static RelativeSource.Self}, Mode=OneTime}"
    }

I believe that this is a bug in the framework as the documentation on Logical Focus states the following:

An element that has keyboard focus will also have logical focus for the focus scope it belongs to; therefore, setting focus on an element with the Focus method on the Keyboard class or the base element classes will attempt to give the element keyboard focus and logical focus.

You can demonstrate that this statement in the documentation is correct by adding the following code to the Window1 class and commenting out the Focus() call in the constructor.

    protected override void OnContextMenuOpening(ContextMenuEventArgs e)
    {
        Debug.Assert(Keyboard.FocusedElement != this || 
                     Keyboard.FocusedElement == FocusManager.GetFocusedElement(this));

        base.OnContextMenuOpening(e);
    }

Now when you right click the window the assertion will fail, because FocusManager.GetFocusedElement() is returning null, but the Keyboard is saying that the Window has the focus.

So there you go, after a lot of stepping through framework code, pulling my hair out and staying up into the wee hours of the morning, I was finally able to figure out what was going on.  I have raised this as a bug on MS connect so if you would like to rate it that might be nice.  The bug can be found here: https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=415864&SiteID=212.

Also when writing this post I found the following article on WPF command routing which explains a few other interesting uses for focus scopes which I found interesting: http://www.aspfree.com/c/a/.NET/More-on-Commands-Input-and-the-WPF/2/

Sometimes it is useful to be able to set bindings on DependencyObjects in code.  If the object you are working in derives from FrameworkElement you can just use the object’s SetBinding method, but what if the object is derived from something else such as a Freezable?  The answer is that you use the static BindingOperations classes' SetBinding method, which unsurprisingly is what the implementation of SetBinding on FrameworkElement calls to do its work anyway.

For that last half a year or so I have been using a solution that I call scratch pad to try out ideas.  For example if I have an idea for some sort of crazy layout panel that I want to try out, but don’t wont to mess around with the project that it is destined for, then I make a new project (or reuse an existing one) in my ScratchPad.sln and try out the idea.  This has worked really well for me, because I typically find it hard to decide on the best way to do something to start with which makes me procrastinate doing it.  Since the scratch pad doesn’t matter and I don’t have to worry about making a mess it is much easier for me to just jump in and try something out.

Lately I have been increasingly frustrated with the designers for WPF.  I would not be at all surprised to find that I would have some of the same frustrations with the Windows forms designer, but some of the frustrations are more WPF specific.  The real problem seems to be that as soon as you do something non trivial the designer will break even though the code runs perfectly fine.  Here are some of the things that are giving me grief at the moment.

1. I moved a style out of a UserControl into a separate ResourceDictionary that is merged into the Application’s resource dictionary.  The designer can still load the user control, but if I try to load the designer for the Window that uses this UserControl it says it can’t find the style.  If I change this style reference to a DynamicResource reference instead of a StaticResource reference then the Visual Studio designer will load, but not Blend.
2. I am using an IoC container (Castle Windsor) in some of my domain objects to provide instances of classes which inherit a certain interface.  The view model which I am using instantiates some of these domain objects and BOOM! the designer can’t cope with setting up the IoC container because it can’t find the config file.  If I hard code the location of the config file in (not desirable, but possibly a liveable workaround when I am in design mode) then I get a different error saying that it couldn’t load the Castle assemblies.  I can’t see why this should happen because they required assemblies are added as references in the project.

The designers are very useful when they are working as they enable you to quickly try out loads of different brushes for styles without having to start the app up each time, but increasingly I find my self fighting with the designer to get it to show me the thing I am interested in so I can work on it.  Maybe I am using the wrong approach to things, but there seems very little documentation of a better way to work with them while actually showing the data you are interested in. 

What would be truly awesome is if you could attach a designer program to a running application and muck around with the properties of the objects while the application was running.  That way you wouldn’t have the problem of not being able to see the working data from the database or some other datasource.

Today I was trying to solve an issue with nunit not setting the correct path for the assembly I was testing’s config file.  Well it wasn’t setting the expected path anyway.  It took me a little while to find out where the application was looking for the config file.  Eventually I discovered the following property: AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.  Hopefully this can be of some use to you in the future.

I had an interesting problem today.  I was running through a foreach loop and generating a linq query with a predicate based on the element I was currently at.  Something a little like this:

            foreach (var sm in new SMRepository())
            {
                var bgvm = new GroupViewModel(this) { Descriptor = sm, Date = DateTime.Today };
                var gb = _workingBSet.Where(b => b.SM == sm);
                bgvm.B = gb; 
            }

Of course the example doesn’t compile and the names have been messed with but you get the idea.  Anyway a problem arose because the query hadn’t actually been run yet.  So when it did come time to run the query all of the results were the same because only the final value of the sm variable was used.  To get around the problem you can either get the count before moving onto the next one, or if you do want the deferred execution you can just make a separate method that does the work.  Something like this:

        void doSomething()
        {
            foreach (var sm in new SMRepository())
            {
                AddGroup(sm);
            }
        }

        private void AddGroup(SM sm)
        {
            var bgvm = new GroupViewModel(this) { Descriptor = sm, Date = DateTime.Today };
            var gb = _workingBSet.Where(b => b.SM == sm);
            bgvm.B = gb;            

            Groups.Add(bgvm);
        }

Today I was working on a custom control that needed to add something to the adorner layer as soon as it was created.  You can’t get it in the constructor, because the control isn’t in the visual tree yet.  The place I ended up deciding to get it was in the OnVisualParentChanged method.  There may be a better place, but this seems to work fine.

I was recently trying to load an image file in a WPF project.  I wanted to load the image file as an ImageSource so I could access its metadata.  I needed a class to wrap the ImageSource so that the class could provide easy access through properties to some metadata values you must use a specific query to access.  Then the wrapped class could be used in an items control with a DataTemplate that could display both the image and the metadata for that image.

Unfortunately it took a little while to find the best way to load the image and still have the metadata available.  You can use the BitmapImage class to load the image easily with just the file path, but then the metadata is not available.  You could also use the approach used in the BitmapMetadata Sample the problem there is that they already know what type of image they are loading so they can instantiate the appropriate encoder easily.  It also seems like a fair bit of work when in the XAML file all you have to do to set a property of type ImageSource is type in the URI.

Of course it is possible to do pretty much the same thing, but I couldn't seem to find anything about in in the MSDN docs (the secret is there, but there aren't any examples of it being used).  Because all values in XAML files are represented as strings they must be converted to the type they are meant to be before they are used.  For example if you set the width property of a Window in a XAML file it must convert the string "1" to the actual integer value 1.  Now it turns out that the String type implements IConvertible which is how most of these conversions takes place.  However before using the IConvertible interface the XAML loader searches the required type of a property for the TypeConverterAttribute.  This attribute basically provides the type name of a class which inherits from TypeConverter.

I then looked up the documentation for ImageSource and saw that the TypeConverter used is of type ImageSourceConverter</A.  Now all I had to do was instantiate one of these and simply call the ConvertFromString method.  As in the following example.

    ImageSourceConverter imgSrcConverter = new ImageSourceConverter();

    Bitmap = imgSrcConverter.ConvertFromString(imageUri) as ImageSource;    

We can learn too things from this.  Firstly we can figure out how to do similar things with other types that are not always so easy to instantiate outside of the XAMl, but are as simple as entering a string in XAML code.  Secondly we now know how we can provide a way for our own classes to be instantiated from a string in a XAML file.

LiveJournal Tags: Snow,Wild Winter Weekend,Tubes

1. Teams of two people
2. Each team gets one tube
3. Both team members must be on the tube as it crosses the finish line

To make it a bit more interesting a number of small jumps are setup in the middle of the half pipe.  This means you might get anything up to half a meter of air which makes staying on the tube a little difficult.  Things normally get pretty hectic as other teams crash in front of you and inevitably you ram into them.

Five teams race down the centre of the pipe at once and only the top two make it through to the next round.  There were three rounds in total with the winner of the third round being the overall winner.

As well as the overall race winners there was also a prize for the best fancy dress.  Josh and I went dressed as a Wookie (think Chubaka from Star Wars, thanks to Ed and Sam for that costume) and the Cookie Monster from Sesame Street (thanks to Gary and Jayne for that one).  The judges couldn't end up deciding which team had the best fancy dress so they split it between four teams including us.  The three other teams that shared in the prize were dressed as the following:

• Two polar bears masquerading as the Bundy Bear.  They also were carrying a box of Bundies with them I think even during the race.
• Two cows which had kind of a clearish fabric with blue cow spots painted on.  They also had pink rubber gloves blown up for udders.
• A guy in a gorilla suit along with another guy in a blow up Santa costume.

Unfortunately Josh and I were knocked out of the race in the first round.  We came in third, but we both think that it should have been second.  The team in front of us didn't look like they were both on the tube as it crossed the line, at least not from our perspective.  The race will be shown on Channel 9 sometime on the 31st of August so we are keen to see a replay to see if we really were jipped or not.

Unfortunately we were a little rushed getting into our costumes and running over to the half pipe for the competition (even though it ended up being a lot later than we were running) so we didn't manage to take any photos of the event.  So if you want to see what it was like you will have to wait for the TV coverage.  Until then you can check out these videos of the tube race from 2000 on YouTube so you can get a feel for the action. Video 1 & Video 2

I bought a new snowboard on Monday from Adrenalin Plus.  All up the gear cost $1,770 with a 15% discount.  I was going to go with a Burton Air, but the chap in the shop convinced me that a Ride Havoc was a better deal.  I got Forum boots and bindings.  The boots were the most comfortable ones in the shop.  Here are some pics.

This morning I was creating a new WPF project in Visual Studio 2008.  I then tried to open that new project in Expression Blend (version 1) only to be greeted with an error message saying "The imported project "C:\Microsoft.CSharp.targets".  I had had this problem before, but I couldn't remember how I fixed it.  I did a quick Google and nothing came up so I thought I would write a blog post about it both for my own reference and for anyone else that has the same problem.

The solutions for me was to open the project file in notepad and then edit the following line:

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

So that it reads like this:

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

The only difference is which variable it is using for the path.

Dependency property value inheritance is a very cool features in WPF.  I recently came across a situation where I wanted to take advantage of an inheriting dependency property, but I had difficulty finding out exactly how to do what I wanted.  I eventually found this article about Property Value Inheritance which gave me the answer I needed.

The problem I had was that I wasn't using an attached property.  I didn't think I needed to do this, because even though I wanted the inheritance to work over two different types of Control I was using the AddOwner method on the original DependencyProperty for my second Control.  However inheritance doesn't work properly in any situation unless it is an attached property.  This wasn't immediately apparent, I had been looking at the FrameworkPropertyMetadataOptions enumeration documentation and it didn't mention anything other than "The values of this dependency property are inherited by child elements" for the Inherits value.  The documentation for WPF is actually quite good, but sometimes it isn't easy to figure out where to look.  The most useful place to start looking for most things seems to be in the WPF Fundamentals page.

To give you an example of why Dependency property value inheritance is a cool feature picture the following situation.  You have an Appointment that contains multiple Bookings.  A Booking represents a period of time where a resource is unavailable.  Resources could be a staff members or rooms.  You decide to have an AppointmentControl that contains multiple BookingControls.  The AppointmentControl knows which Appointment its for and the BookingControl knows which Booking its for.  However the Booking class doesn't have a reference back to its Appointment because it is burdensome to maintain references both ways.  Now imagine that your booking control needs to know which Appointment the booking is for.  Normally you would have to manually set an Appointment property on each BookingControl as it was added and unset it when it was removed, but in WPF you can just make the AppointmentControl's Appointment property an attached inheriting dependency property and then there is no extra work required.  This is just one of the many scenarios where dependency property value inheritance is very useful.

One of the things that has bugged me since moving to Windows Vista is that I was unable to find a way to use tab to navigate auto complete (in places such as windows explorer or the run dialog box). I used to turn this option on under Windows XP by using the TweakUI power toy. I tried googling for a way to turn this option on, but I was unable to find anything. So in search of the answer I turned to the Sysinternals Process Monitor. Using the process monitor I was able to determine which registry key the TweakUI tool changes and make this change on XP and then try the same key on Vista. After making the change and rebooting the auto complete behaved how I wanted it to.

The following is a list of steps that I took to find the registry key and set it. You could use the same steps to find any registry key that is set by TweakUI or any other tool that modifies the registry.  If you are only interested in this one setting and not the technique used to find it then skip to the end of step 4.

NOTE: I recommend that you backup the registry (a system restore point does this) before you modify it

1. Download and Run Process Monitor
   This step is pretty straight forward.
2. Set a filter to only show activity from the TweakUI process
   Open the filter dialog by pressing Ctrl+L (or under the Filter->Filter... menu item) and add a filter like the selected one in the image below.
   
   Once the filter is added click OK.
3. Make the desired change in TweakUI
   In this case we are going to change the Use Tab to navigate AutoComplete option as shown below.
   
   In this case I already have the option checked, so I will uncheck it and then click Apply.  We should notice that a bunch of entries show up in process explorer.
4. Use the Registry Summary tool to find the registry setting(s) that have been changed
   The Registry Summary tool is located in the Tools menu in process monitor.  You should be presented with something like the following.
   
   In this case because we only changed one setting only one registry key was written to.  This is the key we are after and in this case it is HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoComplete\Always Use Tab.
5. Lookup the value in the registry
   Use regedit to find out what the key value should contain.  In this case a value of 1 is on and 0 is off.  Also note the key type.
6. Set the key to the desired value in Vista
   Once the key that is and value that need to be set are found. Opened up regedit on Vista and navigated to the key. It turns out that the AutoComplete key doesn't exist by default under Vista so I create it (using the same type as was used on Windows XP) and the set it to the desired value.
7. Reboot

I was working on an application today where I wanted to setup RoutedCommand that was executed when the user rolled the mouse wheel up.  I also had another RoutedCommand that I wanted to be executed when the mouse wheel was rolled down.  No problem right?  I should just be able to add a MouseGesture to the RoutedCommand's InputGestures collection.  However this isn't the case as their is no MouseAction that differentiates between mouse wheel directions.  There is a MouseWheelClick action that matches when the mouse wheel is moved in any direction.  This seemed a bit strange as I was sure it was something people would want to do fairly frequently.

I did a quick google and found a number of other people that had the same problem.  The solution that had been suggested to them was to just handle the appropriate mouse events and then manually call the command.  I was unhappy with this solution as it kind of defeats the purpose of commands in the first place.  It is also no where near as neat as it requires extra code that could have been more simply defined in XAML rather than code.

So I decided to see if I could create a class that extended MouseGesture that allowed me to create the desired binding.  After a little investigation I discovered that InputGestures have a Matches method that determines if input that has just occurred matches the gesture.  The method has the following signature.

public virtual bool Matches(object targetElement, InputEventArgs inputEventArgs)

I then discovered that when the mouse wheel is moved the InputEventArgs that are passed in are an instance of MouseWheelEventArgs.  MouseWheelEventArgs exposes a property called Delta which gives you amount that the mouse wheel has moved.  Positive values in the Delta property mean that the mouse wheel was rolled up and negative values mean that it was scrolled down.

Armed with this information I set out to make a new class called MouseWheelGesture which looks is shown below.

public class MouseWheelGesture : MouseGesture
    {
        private MouseWheelAction mouseWheelAction;

        public MouseWheelAction MouseWheelAction
        {
            get { return mouseWheelAction; }
            set { mouseWheelAction = value; }
        }

        public MouseWheelGesture()
            : base(MouseAction.WheelClick)
        {
            mouseWheelAction = MouseWheelAction.AllMovement;
        }      

        public override bool Matches(object targetElement, InputEventArgs inputEventArgs)
        {
            if (base.Matches(targetElement, inputEventArgs))
            {
                MouseWheelEventArgs wheelArgs = inputEventArgs as MouseWheelEventArgs;
                if (wheelArgs != null)
                {
                    if (MouseWheelAction == MouseWheelAction.AllMovement
                            ||(MouseWheelAction == MouseWheelAction.WheelDown && wheelArgs.Delta < 0)
                            || MouseWheelAction == MouseWheelAction.WheelUp && wheelArgs.Delta > 0)
                    {
                        return true;
                    }
                }
            }

            return false;
        }
    }

And here is the definition of the MouseWheelAction enum.

    public enum MouseWheelAction
    {
        AllMovement,
        WheelUp,
        WheelDown
    }

So there you have it.  I now have a new type of InputGesture that provides the required functionality in a way that can be easily setup in both code and XAML. 

If at this point if your wondering what commands are in WPF and how they are set up there is a good overview of them on msdn called Commanding Overview