Apparent binding problems with NotSupportedException in PresentationFramework

I ran into this problem twice over the last couple weeks. Perhaps if I write an article, it'll help my future self (and just perhaps someone else) not spend so much time on it...

I put together a simple WPF form with a ListView. The ListLiew's View contained a GridView with columns bound to a POCO's properties. This was all done in XAML. In the constructor, I created an ObservableCollection to contain the objects and set it to the ListView's ItemsSource property. An event fired when interesting things happened. The event handler created the POCO object, set its properties and added it to the collection.

Everything should have worked.

However, when items were added to the collection, the debug window reported:

A first chance exception of type 'System.NotSupportedException' occurred in PresentationFramework.dll

Over the years, I've found data binding to be a challenge to get working. Part of the problem is it's mostly silent when it fails. So, data simply doesn't show up where it's expected with no indication as to why. Because of this, I assumed this is where the problem lay and spent significant time trying to figure out what was happening.

After quite a while I realized the event handler was called from a non-UI thread. I changed the line that added objects to the collection from:

ListViewDetails.Add(detailData);

to:

Dispatcher.Invoke((Action)(() =>
    ListViewDetails.Add(detailData)));

and everything worked properly. A simple solution once I realized what was wrong.

It'd be really nice if the debug window would output the exception message and not just the type. This would have told me immediately what was wrong and I wouldn't have spent so much time going down a dead-end road.

There and back again, again: Any resource's tale

Or, how to generically set and restore state when an exception is raised

I've written twice before (here and here) about making cursor changes more robust with the using statement in C#. These allow states to be reset to correct values regardless of whether or not an exception is raised during some processing. As promised at the end of the last article, today I explain how to use lambdas to easily protect any type of "resource" without having to create a new class or sprinkle your code with try/finally blocks.

To set things up and provide a bit of context, the other day in a code review, I found this:

someFlag = true;
someStartStateMethod();
// Do some work
someResetStateMethod();
someFlag = false;

Over the years, I've seen this pattern repeated, in different domains and different languages and not necessarily limited to setting a flag. Whenever I do, I ask "if an exception happens anywhere in 'do some work,' should the state be reset?" I won't say the answer should always be "yes," but I've not yet found a "no." And this case was no exception.

Since some of the places this was done was nested, I wanted a way to clean all this up that didn't involve adding try/finally blocks. Each try/finally would add another level of indentation; it would get pretty deep pretty fast. Also, it would clutter up the code with noise that didn't really have anything to do with the work needing to be done. In other words, I didn't want this:

someFlag = true;
try
{
   someStartStateMethod();
   try
   {
     // Do some work
   }
   finally
   {
      someResetStateMethod();
   }
}
finally
{
   someFlag = false;
}

In my last article, I separated the code actually handling the protection from the code controlling the invocation of that protection by using inheritance. I created a base abstract class to handle the general IDisposable pattern and descendent classes to handle the actual protection. In that article, I showed a class to handle changing a cursor and then changing it back to the current value.

I quickly realized this code was simply another example of that pattern. I could do the same thing as earlier and put the someStartStateMethod() and someResetStateMethod() in a descendant class. If I followed that pattern, the code under review could be something more along the lines of:

using(new ChangeSomeFlag())
using(new ChangeSomeStateMethod())
{
   // Do some work
}

This is somewhat better.

However, in this case, creating a new class for each thing needing protection didn't seem too appealing. There would be a lot of small special purpose classes, some of which might only be used once. It seemed like a sledgehammer to drive a brad. For this code, I wanted to emphasize composition over inheritance.

Enter lambdas. Because lambdas allow you to treat code as data, they allow easy composition. The LINQ and Rx libraries are great examples. They provide many generic methods (e.g. Where, Select, Any) that have the ability to compose in functionality through the use of lambdas to work on specific types for specialized purposes.

In this particular case, lambdas can be used to contain the code that handles the protection and passed to a class whose sole job is to handle the invocation of that code at the appropriate time. Rewriting the previous example with a new, as yet undefined ResourceProtector class, its use looks like:

using(new ResourceProtector(() => someFlag = true, () => someFlag = false))
using(new ResourceProtector(() => someSetStateMethod(), () => someResetStateMethod()))
{
   // Do some work
}

In this code, two expressions are passed to the constructor of the ResourceProtector class that handle the saving and restoring of state. Here is a single class that can be reused over and over in different situations to protect different types of resources. I think this is a beautiful example of the single responsibility principle combined with the power of lambda expressions to handle composition.

public class ResourceProtector : IDisposable
{
   private bool Disposed { get; set; }
   private Action EndProtection { get; set; }

   public ResourceProtector(Action startProtection, Action endProtection)
   {
      Disposed = false;
      EndProtection = endProtection;
      startProtection();
   }

   public void Dispose()
   {
      DisposeInt();
      GC.SuppressFinalize(this);
   }

   private void DisposeInt()
   {
      if (Disposed)
         return;

      EndProtection();
      Disposed = true;
   }

   ~ResourceProtector()
   {
      DisposeInt();
   }
}

If you have any questions, suggestions or comments, please feel free to leave them below. Until next time, subscribe to the Twitter feed to get notified of future articles and hear about other development related things.

There and back again, again: Several resource's tale

Or, how to safely change a cursor or other resource

In a previous article, I presented a simple class that utilized the IDisposable pattern to set the cursor to a specific value and then automatically reset it to the initial state when some work was accomplished. This simple class had two limitations: it only worked with WPF and it only worked on cursors.

To overcome these limitations, I refactored this to be more general. I changed the context to a generic type and added an abstract RestoreState method that's called when the class is either destroyed (preferred) or the finalizer is called. This allows all the basic plumbing regarding the IDisposable pattern to be contained in one class.

using System;

namespace ResourceProtection
{
    public abstract class ResourceChangeHandler : IDisposable
    {
        protected TContext Context { get; set; }
        private bool Disposed { get; set; }

        protected ResourceChangeHandler(TContext context)
        {
            Disposed = false;
            Context = context;
        }

        public void Dispose()
        {
            DisposeInt();
            GC.SuppressFinalize(this);
        }

        protected abstract void RestoreState(TContext context);

        private void DisposeInt()
        {
            if (Disposed)
                return;

            RestoreState();
            Disposed = true;
        }

        ~ResourceChangeHandler()
        {
            DisposeInt();
        }
    }
}

The beauty of this is it can be used as the base class for specific needs. The function of actually changing a resource is split out from the framework needed to manage the change. Here are three examples: one each for a WPF cursor changer, a WinForms cursor changer and a TreeView BeginUpdate/EndUpdate handler.

How to change a WPF cursor

public class WpfChangeCursor : ResourceChangeHandler{
    private Cursor OriginalCursor { get; set; }

    public WpfChangeCursor(FrameworkElement element, Cursor newCursor)
            : base(element)
    {
        OriginalCursor = Context.Cursor;
        Context.Cursor = newCursor;
    }

    protected override void RestoreState()
    {
        Context.Cursor = OriginalCursor;
    }
}

To use this, instantiate an instance of WpfChangeCursor in a using block, passing in the element who's cursor should be changed and the new value for the cursor. In this case, the context for the base class is the element containing the cursor to be changed. The descendant class has the responsibility to remember the current value and changing the cursor.

How to change a WinForm cursor

public class WinFormChangeCursor : ResourceChangeHandler{
    private Cursor OriginalCursor { get; set; }

    public WinFormChangeCursor(Cursor newCursor)
            : base(Cusor.Current)
    {
        Cursor.Current = newCursor;
    }

    protected override void RestoreState()
    {
        Cursor.Current = Context;
    }
}

This class is used by instantiating an instance of WinFormChangeCursor in a using block with the new value of the cursor passed to it. This is a little different from the WPF version since there is only one cursor for the application, rather than for each element. In this case, the context passed to the base is the current cursor value which is then used by RestoreState to put things back.

How to call BeginUpdate and EndUpdate safely

public class TreeViewUpdate : ResourceChangeHandler{
    public TreeViewUpdate(TreeView treeview)
            : base(treeview)
    {
        Context.BeginUpdate();
    }

    protected override void RestoreState()
    {
        Context.EndUpdate();
    }
}

And finally, here's a class to make sure EndUpdate is called for every BeginUpate on a TreeView. Like the WPF cursor changer above, the control is passed in as the context for the ancestor class. BeginUpdate is then called on the context. When the using block this class is controlled by finishes, the EndUpdate in RestoreState is called, again on the same context as the BeginUpdate.

This technique provides for a level of separation between the framework needed to safely do and undo things from the actual work of doing and undoing them. It works well for certain classes of problems, specifically fixed things that happen over and over again. The examples above of doing repetitive things on framework level items are good examples.

Sometimes though, one wants this type of functionality without the overhead of creating a new class each time. In the next article, I'll present a method of composing this type of behavior in a more adhoc manner.

Until then, subscribe to the Twitter feed to get notified of future articles and hear about other development related things. And if you have any questions, suggestions or comments, please feel free to leave them below.

There and back again: A Cursor's tale

I've been working on UI code recently and have run into this quite a bit:

Cursor = Cursors.Wait;
SomeLongRunningTask();
Cursor = Cursors.Default;

Pretty straight forward code. I see this type of thing a lot, not just in the C# code I'm working on now, but I've seen this in the past. In other languages. On other platforms. It's a common practice. The problem is it only works in some cases.

This will have problems if any method in the "long running task" does the same thing. The cursor will be set back to default prematurely. Of course, this is easily solved by saving the old value prior to setting the new one.

var oldCursor = Cursor;
Cursor = Cursors.Wait;
SomeLongRunningTask();
Cursor = oldCursor;

This is an improvement but will still fail if an exception is raised. This can be fixed with a try/finally.

var oldCursor = Cursor;
Cursor = Cursors.Wait;
try
{
    SomeLongRunningTask();
}
finally            
{
    Cursor = oldCursor;
}

Ok. So now we have some code that works reasonably well. The issue now is one of code maintainability and clarity. Every method that needs to change the cursor needs to add nine lines before it can do any work of its own. It's nine lines where bugs could hide. It's nine lines obscuring the real purpose of the method. There's got to be a better way.

Way back in my Delphi days, I had a small class which handled this chore for me. The constructor took a parameter containing the new cursor. The current cursor was saved in a class field, the cursor was changed and the constructor finished. The destructor simply set the cursor back to the saved value. In that environment, interfaces were reference counted and destroyed when the reference went to zero. The compiler took care of all the bookkeeping automatically. So I could create an instance of this class, store it in a local variable and, when the variable went out of scope, the object was destroyed, resetting the cursor. It worked really well. One line to change the cursor to whatever I wanted and it automatically reset to the original value when done. Pretty sweet.

Unfortunately, C# does not have any deterministic way of handling object lifetimes. This is one of my biggest frustrations with the language. The closest thing we have is the hack that is the using statement. Since this is the best we have, I have put together a class, shown below, similar to the one I had before. The constructor takes the new cursor value and control whose cursor should be changed, saves the current one and, in the Dispose method, resets it back. Now we can have three simple lines with one code block rather than the nine lines with two blocks. It's a big improvement although still not the single line like I'd prefer.

In use, it looks like this:

using ChangeCursor(this, Cursors.Wait)
{
    SomeLongRunningTask();
}

Arguably, this is a bit cleaner than even the first code snippet we started with.

Since this takes a FrameworkElement, it's WPF specific. It'd be easy enough to change the type to work with WinForms, if needed. The same technique could be used to handle other things where a state needs to be set to one value and then reset when some unit of work is done. For example, if using TreeViews with BeginUpdate/EndUpdate pairs.

Hope this helps someone.

using System;
using System.Windows;
using System.Windows.Input;

namespace CursorResourceProtection
{
    public class ChangeCursor : IDisposable
    {
        private FrameworkElement Context { get; set; }
        private bool Disposed { get; set; }
        private Cursor OriginalCursor { get; set; }

        public ChangeCursor(FrameworkElement context, Cursor newCursor)
        {
            Disposed = false;
            Context = context;
            OriginalCursor = context.Cursor;
            context.Cursor = newCursor;
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            if(Disposed)
                return;

            Context.Cursor = OriginalCursor;
            Disposed = true;
        }

        ~ChangeCursor()
        {
            Dispose(false);
        }
    }
}

Canceling application shutdown in WPF

I hate "Are you sure" type dialog boxes. Gratuitous use of them in software makes me want to do violence to whoever thought it was a good idea to put it in. That said, there are a few times where they make sense. For example, the application I'm working on now controls an instrument that may have some expensive, hard to replace, chemistry in it. Stopping the application while the instrument is in use may result in moderate financial loss, so in this case, it does make sense to alert the user to a possible undesired outcome and make sure they really want to proceed with the action.

The WPF Window class has a Closing event that fires when the window is closed. This event has an argument containing a Cancel property with a false default value. Setting this property to true inhibits the closing of the window. When this happens on the application’s MainWindow, this closing cancellation behavior applies to the application as a whole.

Some time ago, our application had code put in to pop up an “Are you sure?” style dialog and set the event's property as appropriate. The problem was it worked for some pathways through the code but not others. The lot fell to me to investigate. There are four ways to close the application: the Alt-F4 key, the task bar's Close option, the Close button in the window's title bar and an Exit menu option. All the methods worked except the Exit menu.

Digging into the code, the Exit method menu called the Shutdown method on the Application.Current object. This seemed like a reasonable thing to do and I went looking elsewhere for the problem. After spending time verifying there wasn't anything else odd in our code I came back to this method. On a hunch, I changed this to calling the Close method on Application.Current.MainWindow. This fixed the problem. I'm not sure why, but apparently the Shutdown method does something to inhibit the normal message processing of open windows.

I know this is typical behavior and it fixes my application for now, but from a design standpoint, I'm not too sure I like this. It seems like application level shutdown code in the Window is at the wrong layer. The Application class has an Exit event that's analogous to the Window's Close event however, this does not allow canceling the operation. In my opinion, the Application class should have an Exiting event with a Cancel property on the argument, similar to the Window class' Closing event.

In any case, if your application does not call the Closing event as you expect, first check to see how it's shutdown.

(25-June-2012: Minor edit for clarity.)

How to display items from a collection in one line of a DataGrid

Typically, data structures map closely to their representation in the user interface and so most display widgets work pretty well in this situation. In WPF, DataContexts and bindings expect the relationship between their controls and the bound data to be fairly similar. Recently, I had a weird requirement that caused me trouble getting information on the screen due to a mismatch between the data model and the view.

Requirements

For good reasons, the data needed to be modeled in a master-detail relationship. For equally good reasons, the user wanted this displayed on a single line in a grid control. I believe the model to be correct; I'm not too sure about the user interface. I understand the user's reasons for wanting a single line, but I expect that over time and as new features are added, they will want a change in how things are presented. Regardless of what happens in the future, for today, this is the current requirement that I had to implement.

So, the data model looked something like this: 

And, with the assumption that there will not be more than one instance for any particular descendant type of TestItem in Property3, the goal was to have a screen that looked like this:

The problem

Setting up the data structures was no problem, nor was getting the master's data on the screen. I used a DataGrid from WPFTools and simple binding sufficed for Property1 and Property2. But when it came to PropertyA1 and PropertyB1 I ran into problems. Reading the documentation for binding paths, I found I could use the slash character to indicate items in a collection. Going down this trail, I tried setting the paths for the last two columns to Property3/PropertyA1 and Property3/PropertyB1. This sort of worked:

As shown above, the correct data is displayed, but only for the first item in the list. If the order of things in the list is changed, the data changes appropriately. Through the binding path, I could find no way to select different items from the list for different columns in the grid. Perhaps it can be done and I didn't find how, but understandably, this is an odd thing to try to do and it's not a surprise if the framework doesn't support it. (See CollectionBinding1 in the source code.)

Solution: IValueConverter

I thought about trying to put the data in the cells directly without binding and, while searching how to do this, was reminded of IValueConverter. From the examples, the standard way of using this is to simply convert between types or to control formatting. However, I realized I could create one that takes the entire list and pulls out from it a specific field.

First, I changed the binding for the two problematic columns to be just Property3. Then I created a new converter class for each property, and finally instantiated and assigned them to the columns' bindings. This resulted in a one-to-one relationship between converter classes and each property. The converters iterated the list until an entry of its expected type was found and then returned the field value it knew about. A converter for each property: ugly, but it worked! (See CollectionBinding2 in the source code.)

After proving the concept, I looked to clean it up a bit. The only differences between the classes was the type it was looking for and the property it returned. I realized these two things could be parameterized. I could change the converter to a generic class and then use the generic type in the loop. Also, I could pass a lambda expression to the constructor that would later be used in the loop to get the property value if the given type was found. I made these relatively minor changes, eliminating the multiple classes and making the strategy effective for my real world scenario. (See CollectionBinding3 in the source code.)

Final thoughts

Typically, converters are instantiated and referenced in the XAML code with just the implementation residing on the C# side. This works because the number of types are relatively small. My original implementation would probably work with this usage pattern, however, in the real world situation, with its one-to-one relationship between properties and converter classes, I would have an inordinate number of classes to have to manage. By moving the instantiation into C#, I can use a single class to handle the different types of objects in the list and the multiple properties in each type.

Source code for the three stages of development is available in a zip file here.

Any comments are welcome.

How to display tool tips in WPF DataGrid text column

Like many people before me, while using the DataGrid from the WPFtoolkit, I recently had a requirement to display text nicer than the default. First, the default is simply to truncate the text like so:

I needed the truncated text to have ellipses after it and have a ToolTip showing the entire text. Something like this:

I did a lot of searching the web and didn't find anything straight-forward and elegant. I found things that intimated using styles in XAML might work, although nothing directly addressing what I wanted to do. Furthermore, I found others saying XAML styles won't work at all for cell level changes along with some ugly hacks where, inside the LoadingRow method, they walked back up the VisualTree to change the cell style in code. My search was confounded by the fact that there are a number of different DataGrid components, three by Microsoft (WinForms, WPF and Silverlight) and several by other 3rd party vendors. All have issues doing this very basic thing and all with different workarounds.

After spending the better part of a day researching and testing various possible solutions, I found a comment on a Silverlight forum with the idea of using a DataGridTemplateColumn descendant to handle the new needs. I started to adapt the example code from Silverlight to WPF and thought, "There must be an easier way." Since the existing DataGridTextColumn already did much of what was in this example, I went off to look at its source code. While browsing through it, I found a protected virtual method called GenerateElement that apparently is a factory for the cells' display. On a hunch, I created a descendant of this column type and overrode this one method, changing the properties of the returned value as needed.

Amazingly, it worked the first time. So, to add my own workaround to the mix that's found on the web, here is the class I created:

public class DataGridToolTipTextColumn : DataGridTextColumn
{
    protected override FrameworkElement GenerateElement(DataGridCell cell, object dataItem)
    {
        var result = (TextBlock)base.GenerateElement(cell, dataItem);
        result.TextTrimming = TextTrimming.CharacterEllipsis;
        ApplyBinding(result, FrameworkElement.ToolTipProperty);
        return result;
    }

    // Copied from DataGridTextColumn because it's not protected there either. Seems like it should be.
    internal void ApplyBinding(DependencyObject target, DependencyProperty property)
    {
        var binding = Binding;
        if (binding == null)
            BindingOperations.ClearBinding(target, property);
        else
            BindingOperations.SetBinding(target, property, binding);
    }
}

The GenerateElement method simply calls the base class and typecasts the return value to a TextBlock. For the moment this is safe since the base class has the type hard coded. The TextTrimming property is then set for CharacterEllipsis and the ToolTip property is bound to the same value as the Text property. This class is twice as long as it needs to be because the ApplyBinding method that exists in the base class is marked internal rather than protected, so I simply made a copy of it for use here.

In my usage, this DataGrid is only to display information; editing is turned off. I haven't checked to see if this would cause any issues in edit mode.

Related material

In all this searching, I did find a couple good resources:

• Samuel Moura has a 4 part series doing some pretty intensive DataGrid styling and templating: Introduction, Custom Styling, Playing with Columns and Cells and TemplateColumns and Row Grouping.
• The Tranxition Developer Blog has a good article on adding dependency properties to the TextBlock type. Unfortunately, this doesn't seem to work for TextBlocks that are in another control's VisualTree.
• This Silverlight thread is what gave me the idea for creating a descendant class.
• I ran across this great little utility called Snoop to inspect the VisualTree of a running WPF application. I think I'd heard of it before in passing but had never looked into it. I don't know how many times I've written throw-away VisualTree walkers to dump information to the console. Now I'll never have to do that again.

WPF Colors, static classes and reflection in .Net

Today I wanted to know the definitions of the colors in WPF's static Colors class. A two-minute web search didn't turn anything up so I decided to write a quick and dirty little program to emit them. It should have been simple enough; I should have known better.

Using reflection, I wanted to cycle through each property of the Colors class and output its name and RGB value. To this end, I typed this into Visual Studio:

foreach (var prop in typeof(Colors).GetProperties())
{
    var propColor = (Color)prop.GetValue();
}

Then I hit a snag: GetValue wanted an instance of the class. However, Colors is static and I could not create an instance of it. In looking through the interface, I found GetConstantValue method. That sounded promising. I tried it. It compiled but threw an exception at run-time indicating it wasn't going to work.

I read the PropertyInfo documentation and didn't see anything more promising than GetValue. I searched the web some more but the only thing I could find talked about calling static methods on normal classes with instances of them created. I went back to the documentation where the description for the first parameter still said "The object whose property value will be returned." Reading on, the second parameter was the index value and said, "This value should be null for non-indexed properties."

Hmm... What happens if the first parameter is null?

Having nothing to lose, I tried it with both parameters passed as null. It compiled. A breakpoint set after the assignment and then inspection of propColor indicated it worked as expected. Cool!

I put a WrapPanel in the XAML file and named it ColorItems. Then I fleshed out my for loop:

foreach (var prop in typeof(Colors).GetProperties())
{
    var propColor = (Color)prop.GetValue(null, null);
    var desc = string.Format("{0} ({1})", prop.Name, propColor);
    Console.WriteLine(desc);
    ColorItems.Children.Add(new Grid
        {
            Width = 20,
            Height = 20,
            Margin = new Thickness(2),
            ToolTip = desc,
            Background = new SolidColorBrush(propColor)
        });
}

This gave me a nice little window with squares of color. Each square showed a tool tip with the name and color. Moreover, I had the table shown below in the Output window of the IDE.

Download the zipped project with compiled application.

Color	Value	Sample
AliceBlue	#F0F8FF
AntiqueWhite	#FAEBD7
Aqua	#00FFFF
Aquamarine	#7FFFD4
Azure	#F0FFFF
Beige	#F5F5DC
Bisque	#FFE4C4
Black	#000000
BlanchedAlmond	#FFEBCD
Blue	#0000FF
BlueViolet	#8A2BE2
Brown	#A52A2A
BurlyWood	#DEB887
CadetBlue	#5F9EA0
Chartreuse	#7FFF00
Chocolate	#D2691E
Coral	#FF7F50
CornflowerBlue	#6495ED
Cornsilk	#FFF8DC
Crimson	#DC143C
Cyan	#00FFFF
DarkBlue	#00008B
DarkCyan	#008B8B
DarkGoldenrod	#B8860B
DarkGray	#A9A9A9
DarkGreen	#006400
DarkKhaki	#BDB76B
DarkMagenta	#8B008B
DarkOliveGreen	#556B2F
DarkOrange	#FF8C00
DarkOrchid	#9932CC
DarkRed	#8B0000
DarkSalmon	#E9967A
DarkSeaGreen	#8FBC8F
DarkSlateBlue	#483D8B
DarkSlateGray	#2F4F4F
DarkTurquoise	#00CED1
DarkViolet	#9400D3
DeepPink	#FF1493
DeepSkyBlue	#00BFFF
DimGray	#696969
DodgerBlue	#1E90FF
Firebrick	#B22222
FloralWhite	#FFFAF0
ForestGreen	#228B22
Fuchsia	#FF00FF
Gainsboro	#DCDCDC
GhostWhite	#F8F8FF
Gold	#FFD700
Goldenrod	#DAA520
Gray	#808080
Green	#008000
GreenYellow	#ADFF2F
Honeydew	#F0FFF0
HotPink	#FF69B4
IndianRed	#CD5C5C
Indigo	#4B0082
Ivory	#FFFFF0
Khaki	#F0E68C
Lavender	#E6E6FA
LavenderBlush	#FFF0F5
LawnGreen	#7CFC00
LemonChiffon	#FFFACD
LightBlue	#ADD8E6
LightCoral	#F08080
LightCyan	#E0FFFF
LightGoldenrodYellow	#FAFAD2
LightGray	#D3D3D3
LightGreen	#90EE90
LightPink	#FFB6C1
LightSalmon	#FFA07A
LightSeaGreen	#20B2AA
LightSkyBlue	#87CEFA
LightSlateGray	#778899
LightSteelBlue	#B0C4DE
LightYellow	#FFFFE0
Lime	#00FF00
LimeGreen	#32CD32
Linen	#FAF0E6
Magenta	#FF00FF
Maroon	#800000
MediumAquamarine	#66CDAA
MediumBlue	#0000CD
MediumOrchid	#BA55D3
MediumPurple	#9370DB
MediumSeaGreen	#3CB371
MediumSlateBlue	#7B68EE
MediumSpringGreen	#00FA9A
MediumTurquoise	#48D1CC
MediumVioletRed	#C71585
MidnightBlue	#191970
MintCream	#F5FFFA
MistyRose	#FFE4E1
Moccasin	#FFE4B5
NavajoWhite	#FFDEAD
Navy	#000080
OldLace	#FDF5E6
Olive	#808000
OliveDrab	#6B8E23
Orange	#FFA500
OrangeRed	#FF4500
Orchid	#DA70D6
PaleGoldenrod	#EEE8AA
PaleGreen	#98FB98
PaleTurquoise	#AFEEEE
PaleVioletRed	#DB7093
PapayaWhip	#FFEFD5
PeachPuff	#FFDAB9
Peru	#CD853F
Pink	#FFC0CB
Plum	#DDA0DD
PowderBlue	#B0E0E6
Purple	#800080
Red	#FF0000
RosyBrown	#BC8F8F
RoyalBlue	#4169E1
SaddleBrown	#8B4513
Salmon	#FA8072
SandyBrown	#F4A460
SeaGreen	#2E8B57
SeaShell	#FFF5EE
Sienna	#A0522D
Silver	#C0C0C0
SkyBlue	#87CEEB
SlateBlue	#6A5ACD
SlateGray	#708090
Snow	#FFFAFA
SpringGreen	#00FF7F
SteelBlue	#4682B4
Tan	#D2B48C
Teal	#008080
Thistle	#D8BFD8
Tomato	#FF6347
Transparent	#FFFFFF
Turquoise	#40E0D0
Violet	#EE82EE
Wheat	#F5DEB3
White	#FFFFFF
WhiteSmoke	#F5F5F5
Yellow	#FFFF00
YellowGreen	#9ACD32

WPF DataGrid binding weirdness

Recently I had an object with a read-only property that I wanted to bind to a WPF DataGrid column. I expected an easy Binding="{Binding Path=MyProperty}" to accomplish it. However, when I made this change and tried to display the data at run-time, I got a bunch of exceptions:

A TwoWay or OneWayToSource binding cannot work on the read-only property 'MyProperty' of type 'MyObject'.

"Ok," I thought, "just change the binding's Mode."

So I assigned the value OneWay to Mode in the binding: Binding="{Binding Path=MyProperty, Mode="OneWay"}.

Same thing. No difference. Huh!?!?

After a bit of head scratching and digging through search results, I set the IsReadOnly property on the column to true.^[1] That worked!

I removed the Mode assignment from the binding. It still worked!

Apparently, the DataGrid ignores the binding mode and sets it to what it thinks it should be, regardless of what it's told. Frustrating.

---

1. This post on GenericError.com pointed me in the right direction.

Microsoft's OfficeUI Ribbon: Adding non-button controls

There are quite a few controls included with the new Microsoft OfficeUI Ribbon library. I recently wanted to incorporate this into a prototype application I was working on. All the examples I found showed how to use it with a button but I wanted a richer UI than just buttons on the ribbon. I did some web searching and found precious little information on using other controls and I did not find any documentation. Using the little information I did find, a lot of reverse engineering and some trial and error, I finally came up with something that works. Therefore, in an effort to help someone else, here are some things I discovered.

First, I wanted a simple mini-form for doing text searches. All it needed was an edit box, a go button and a couple check boxes in a ribbon group. Here is a screen shot of what I wanted:


In my first attempt, I knew I needed a group to put the controls in, so I naively added one to my ribbon and added the desired controls. The designer immediately became unstable. I was able to compile after stopping and restarting the IDE. However, when running the application, I got a null reference exception loading the form.

Through some routine diagnostic sleuthing, I determined the cause: having multiple groups without assigning GroupSizeDefinitions. If there is only one group, it will work properly without defining a GroupSizeDefinition. However, with more than one group, each group must have a GroupSizeDefinition assigned. I hope that Microsoft will fix this bug before the final release.

In spite of fixing the null reference problem, the layout did not work as desired. Things did not size appropriately. Controls did not position the way I wanted. It was a UI mess.

I had gone to a session at PDC2008 where they demonstrated the control so I went to find that presentation. A bit of information was gleaned from slide 36 [pptx] of session PC45 where the ItemsPanel property was discussed. Unfortunately it was entirely too brief and ended up somewhat misleading. It did give me a clue to start looking for other things though.

After a bit of searching, reading blog articles and forum posts, I found the key to figuring this out in a short post by Mike Cook. I found it best to add an ItemsPanel to the RibbonGroup containing a UniformGrid. The controls then went in this container.

In order to get the controls formatted the way I wanted, I needed to put each row in a DockPanel. However, the only things that can go in a RibbonGroup are things that implement IRibbonControl. To handle this, I created two of my own controls that extend DockPanel and implement IRibbonControl. This ended up working well because I needed to add additional code to each one to work the way I wanted and this helped encapsulate this code.

In formatting the top line, the first thing I found was the RibbonButton, used for the Go function, always assumes there is an image associated with it. For the purposes of this form, I wanted the image to the left of the label, associated with the entire line, not over on the right associated with the button. In order to turn this off, I had to find the image in the button's template and set its Visibility to Collapsed.

After getting the button's image removed, the next thing I found was the RibbonTextBox sizes the text box to its content. This seemed ugly to me and I did not find any way of altering this behavior with simple property settings so I started investigating the VisualTree for the control. After some trial and error, I found I could set the Width of a Border inside the RibbonTextBox and the internal TextBox would remain that size. This strikes me as a pretty ugly and fragile hack, but it works. I hope that this will improve before the final release.

The second row is more straightforward with just two RibbonCheckBoxes on it. It does have a slight oddity though. The Executed property must have a method assigned to it for the check box to be active. The issue is, in this particular use case, I did not need to have anything happen when the user checks the box so there is a required method that has nothing in it. This seems silly to me.

At the end of the day, I was able to get what I wanted out of the library. I think it looks nice for the user and functions well. But, it is not terribly pretty for the programmer and there was quite a bit of frustration getting it to work as I intended, mostly due to poor and lacking documentation. I hope someone else finds this useful. If there are any errors or omissions, please leave a comment to let me know and I will do my best to correct it.

Source code

The ribbon control is publicly available on the OfficeUI web site after agreeing to a long, overwhelming license. (Here are the how-to-get instructions.) As I understand it, this is going to be bundled into the base System.Windows name space with CLR 4.0, so I'm not quite sure why there's such an onerous license on it at this point.

Here is complete source code [zip] for this article. Note that it does contain a reference to RibbonControlsLibrary, the package containing the Ribbon controls, which is not included due to licensing restrictions. In order for this to compile, you need to get this library from Microsoft (see links above) and then update this project to point to your copy of it.

Microsoft's OfficeUI Ribbon: Application template

I've been working with the recently released Ribbon control from Microsoft's Office UI group. There are several cookie-cutter setup steps to get an application ribbon aware. In order to facilitate setting up a new application, I made a Visual Studio 2008 template that creates a blank application containing a ribbon bar with some empty controls.

Here is the template file. Copy this zip file to My Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C#. When Visual Studio is started, the New project dialog displayed when File | New | Project... will have a new Ribbon Application option under My Templates. Select this to create a skeleton ribbon application.

When the application is created, an error will be displayed indicating the ribbon control library cannot be found. This is because this library needs to be acquired directly from Microsoft. To get it you need to go to the OfficeUI web site. (Here are the how-to-get instructions.)

Once the library is downloaded and installed on your computer, go to the new ribbon application's References, remove RibbonControlsLibrary and then add it in again, pointing to the location on your computer.

The skeleton application contains a Close option on the application menu to stop the application. There is a single tab with a single group containing a single button. Finally, there is a single button on the quick access toolbar. These all can be used as templates to easily add more.

More information on creating Visual Studio templates can be found on the MSDN site. (Thanks to paranoid ferret for the pointers on to how to create templates.)