views:

3946

answers:

7

In WPF, it seems to be impossible to select (with the mouse) a "null" value from a ComboBox. Edit To clarify, this is .NET 3.5 SP1.

Here's some code to show what I mean. First, the C# declarations:

public class Foo
{
    public Bar Bar { get; set; }
}

public class Bar 
{
    public string Name { get; set; }
}

Next, my Window1 XAML:

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <StackPanel>
        <ComboBox x:Name="bars" 
                  DisplayMemberPath="Name" 
                  Height="21" 
                  SelectedItem="{Binding Bar}"
                  />
    </StackPanel>
</Window>

And lastly, my Window1 class:

public partial class Window1 : Window
{
    public Window1()
    {
        InitializeComponent();

        bars.ItemsSource = new ObservableCollection<Bar> 
        {
            null, 
            new Bar { Name = "Hello" }, 
            new Bar { Name = "World" } 
        };
        this.DataContext = new Foo();
    }
}

With me? I have a ComboBox whose items are bound to a list of Bar instances, one of which is null. I have bound the window to an instance of Foo, and the ComboBox is displaying the value of its Bar property.

When I run this app, the ComboBox starts with an empty display because Foo.Bar is null by default. That's fine. If I use the mouse to drop the ComboBox down and select the "Hello" item, that works too. But then if I try to re-select the empty item at the top of the list, the ComboBox closes and returns to its previous value of "Hello"!

Selecting the null value with the arrow keys works as expected, and setting it programatically works too. It's only selecting with a mouse that doesn't work.

I know an easy workaround is to have an instance of Bar that represents null and run it through an IValueConverter, but can someone explain why selecting null with the mouse doesn't work in WPF's ComboBox?

+1  A: 

Hi,

this might not address your answer completely, but hopefully its a hit in the right direction:

  1. Have you installed SP1?

From Scott Gu's Blog:

  • NET 3.5 SP1 includes several data binding and editing improvements to
    WPF. These include:
  • StringFormat support within {{ Binding }} expressions to enable easy formatting of bound values
  • New alternating rows support within controls derived from ItemsControl, which makes it easier to set alternating properties on rows (for example: alternating background colors)
  • Better handling and conversion support for null values in editable controls Item-level validation that applies validation rules to an entire bound item
  • MultiSelector support to handle multi-selection and bulk editing scenarios
  • IEditableCollectionView support to interface data controls to data sources and enable editing/adding/removing items in a transactional way
  • Performance improvements when binding to IEnumerable data sources

Sorry if I wasted your time and this was not even close..but I think the problem is inherited from:

constraints of the strongly typed dataset

NullValueDataSet Explained here

But now the SP1 for .Net 3.5 should have addressed this issue..

Ric Tokyo
Yep, .NET 3.5 SP1. Confirmed on two different machines (saw it first in a different project on a co-worker's so I wrote this test program on my own).
Matt Hamilton
A: 

Try Binding.FallbackValue

From 6 Things I Bet You Didn't Know About Data Binding in WPF

rudigrobler
Rudi,I get that FallbackValue would be useful when using the null object pattern, but how would it help when I want to explicitly have "null" as an option? Can you update your answer with some XAML or code?
Matt Hamilton
A: 

Hi, I had the same kind of problem we did some work around like adding a value property to the collection item like this :

 public class Bar

   {
      public string Name { get; set; }
      public Bar Value
      {
         get { return String.IsNullOrEmpty(Name) ?  null :  this; } // you can define here your criteria for being null
      }
   }

Then while adding items instead of null I use the same object :

  comboBox1.ItemsSource=  new ObservableCollection<Bar> 
        {
            new Bar(),
            new Bar { Name = "Hello" }, 
            new Bar { Name = "World" } 
        };

And instead of selecteditem I bind it to selectedvalue :

<ComboBox Height="23" Margin="25,40,133,0" DisplayMemberPath="Name"
              SelectedValuePath="Value" 
              SelectedValue="{Binding Bar}"
              Name="comboBox1" VerticalAlignment="Top" />

I know It is not a complete solution, just one workaround I use

Dincer Uyav
Yes, that's exactly what I meant by " have an instance of Bar that represents null" in the last paragraph of my question.
Matt Hamilton
A: 

ComboBox needs a DataTemplate to display the item no matter how simple it is. DataTemplate works like this: get a value from instance.[path], e.g.

bar1.Car.Color

So it cannot get a value from

null.Car.Color

It will throw a null reference exception. So, the null instance will not be displayed. But the the Color - if it is a reference type - is allowed to be null because there will be no exception in this case.

redjackwong
But the null instance *is* displayed - it's displayed as a blank item in the list, and it's possible to select using the keyboard. It's only when you try to select it with the mouse that the ComboBox reverts back to its previous value. I understand your logic but the evidence doesn't support it.
Matt Hamilton
Sorry for my quick answer without trying it out. I will give another answer below.
redjackwong
A: 

I know this answer isn't what you asked for (an explanation of why it doesn't work with the mouse), but I think the premise is flawed:

From my perspective as a programmer and user (not .NET), selecting a null value is a bad thing. "null" is supposed to be the absence of a value, not something you select.

If you need the ability explicitly not to select something, I would suggest either the work-around you mentioned ("-", "n.a." or "none" as a value), or better

  • wrap the combobox with a checkbox that can be unchecked to disable the combobox. This strikes me as the cleanest design both from a user's perspective and programmatically.
Galghamon
Yes, that's exactly what we've done. And yes, I agree it doesn't answer the question. :)
Matt Hamilton
A: 

Just a guess, but I think it sounds reasonable.

Assume combobox is using "ListCollectionView" (lcv as its instance) as its item collection, which it should be. If you are a programmer, what you gonna do?

I will respons to both Keyboard and Mouse.

Once I get Keyboard input, I use

lcv.MoveCurrentToNext();

or

lcv.MoveCurrentToPrevious();

So, sure keyboard works well.

Then I am working on respons Mouse inputs. And it comes the problem.

  1. I want to listen 'MouseClick' event of my item. But probably, my Item doesn't generated, it is just a placeholder. So when user click on this placeholder, I get nothing.

  2. If I get the event successfully, what's next. I will invoke

    lcv.MoveCurrentTo(selectedItem);

the "selectedItem" which would be null is not an acceptable parameter here I think.

Anyway, it's just guessing. I don't have time to debug into it though I am able to. I have a bunch of defects to fix. Good Luck. :)

redjackwong
+2  A: 

The null "item" is not being selected by the keyboard at all - rather the previous item is being unselected and no subsequent item is (able to be) selected. This is why, after "selecting" the null item with the keyboard, you are thereafter unable to re-select the previously selected item ("Hello") - except via the mouse!

In short, you can neither select nor deselect a null item in a ComboBox. When you think you are doing so, you are rather deselecting or selecting the previous or a new item.

This can perhaps best be seen by adding a background to the items in the ComboBox. You will notice the colored background in the ComboBox when you select "Hello", but when you deselect it via the keyboard, the background color disappears. We know this is not the null item, because the null item actually has the background color when we drop the list down via the mouse!

The following XAML, modified from that in the original question, will put a LightBlue background behind the items so you can see this behavior.

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <StackPanel>
        <ComboBox x:Name="bars" Height="21" SelectedItem="{Binding Bar}">
            <ComboBox.ItemTemplate>
                <DataTemplate>
                    <Grid Background="LightBlue" Width="200" Height="20">
                        <TextBlock Text="{Binding Name}" />
                    </Grid>
                </DataTemplate>
            </ComboBox.ItemTemplate>
        </ComboBox>
    </StackPanel>
</Window>

If you want further validation, you can handle the SelectionChanged event on the ComboBox and see that "selecting the null item" actually gives an empty array of AddedItems in its SelectionChangedEventArgs, and "deselecting the null item by selecting 'Hello' with the mouse" gives an empty array of RemovedItems.

Tim Erickson
Brilliant! That makes sense. Thanks Tim.
Matt Hamilton