{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type Window}}, Path=.}

In fact this doesn’t really work. The problem is the path. You can define any child element via the path reference, btu I have not seen an easy way to define the einter window in the path. “.” doesn’t work. I’d imagine there is a way to do it with something like {RelativeSource Self} but I have not had time to research this further.

Why not? What I’ve got works and reworking existing code is kind of a waste of time when I’m not feature complete yet.

View Model Code:

public Media Media { get; set; }
public List<media> MediaList { get { return Enum.GetValues(typeof (Media)).Cast</media><media>().ToList(); } }

XAML Code:

<ComboBox
  x:Name="cbxMedia"
  ItemsSource="{Binding MediaList}"
  SelectedItem="{Binding Media}"
  IsSynchronizedWithCurrentItem="True"
/>

When the user changes selections on the screen, the background value is automatically converted to the correct enum value. I had been thinking that everything had to be converted in to and out of string based objects. Nope. That is not to say that I am using a best practice. I’m still gaining experience with WPF and the M-V-VM pattern.

Of course, the other way to do this would be to express the enumeration as static resource in the XAML. I looked at it. I got it working, then decided that I was breaking too many rules because the View would have to know about the underlying business object. The whole point in M-V-VM is to create ignorant Views. The data context is the only thing the View should know. So no embedded info on business layer objects.

This works and it is simpler. Simpler is always better, but not too simple. To paraphrase Einstein.

Then again, maybe there’s a better way to use the tool… My just managing your docs and not Visual Studio Project files would be more practical.

I’ll have to find something I like and get the legal stuff worked out to post them here. We’ll see what comes. I’m working on it.