Binding const member in code behind from xaml in WPF

Aki24x picture Aki24x · Mar 16, 2011 · Viewed 14.7k times · Source

Is there any good way to bind a property to a const value in codebehind?

When I use ComboBox, I usually do this way in xaml and code behind:

XAML:

<ComboBox Name="cbBuz">
   <ComboBoxItem Content="foo" Uid="foo" IsSelected="true" />
   <ComboBoxItem Content="bar" Uid="bar" />
</ComboBox>

Codebehind:

ComboBoxItem item = cbBuz.GetSelectedItem();
switch (item.Uid)
{
    case "foo":  ... break;
    case "bar":  ... break;
}

The reason why I chose this way is following:

  • For localization purpose, Content string should not be used to determine which item is selected during saving and loading a last selected item.
  • For simplicity, XAML and code-behind should be connected internal identifier (In this case, Uid). So that, XAML and Code-behind can be maintained separately.

However, maintenance-wise, the internal identifier should be defined in one-place like this:

//IDs
public const string ID_foo = "foo";
public const string ID_bar = "bar";

...

//
switch (item.Uid)
{
    case ID_foo:  ... break;
    case ID_bar:  ... break;
}

The problem is seemingly property cannot be const value, so there's no way to bind ID_foo and ID_bar to Uid of ComboBoxItem like this:

//If ID_foo and ID_bar are properties, this will work.
<ComboBox Name="cbBuz">
   <ComboBoxItem Content="foo" Uid="{Binding ID_foo}" IsSelected="true" />
   <ComboBoxItem Content="bar" Uid="{Binding ID_bar}" />
</ComboBox>

So, I want to know how to solve this issue. Or, is there any better way to implement it. It would be nice, too.

Best,

Answer

CodeNaked picture CodeNaked · Mar 16, 2011

You would be better off using the StaticExtension, like so:

Uid="{x:Static local:YourClass.ID_foo}"

Where local is an xmlns alias for the C# namespace of your class. More information can be found here.

The problem with using Binding is you are adding a lot overhead for something that will never change. The binding will attempt to monitor your property. Also, there are known "leaks" with using a Binding with a non-dependency property on an object that don't implement INotifyPropertyChanged.