My previous post was about not being able to bind to a named element outside of your scope. With the help of some great people, we figured out a workaround: you can bind to an ancestor. So, this does work:

<StackPanel DataContext="{Binding ElementName=lb, Path=SelectedItem}">
<ListBox Name="lb" ItemsSource="{Binding Source={StaticResource InventoryData}, XPath='Book'}" IsSynchronizedWithCurrentItem="True" />
<local:CustomItemsControl ItemsSource="{Binding RelativeSource={RelativeSource AncestorType={x:Type StackPanel}}, Path=DataContext}" />
</StackPanel>

This has a listbox that binds to a datasource (xml this time) and a stackpanel above it binds it's datacontext to the selecteditem of the listbox.
Obviously this has all kinds of nasty smells surrounding it.... Next please!

We might not be able to bind to a named element outside of scope, but if we can bind to an ancestor, chances are good that we can bind to a staticResource as well. So let's introduce a CollectionView around our XML datasource. In the Window.Resources:
<CollectionViewSource x:Key="InventoryView" Source="{Binding Source={StaticResource InventoryData}, XPath='Book'}" />

And then we can bind to the currentitem of this view, instead of the ugly datacontext of the parent stackpanel:

<StackPanel >
<ListBox Name="lb" ItemsSource="{Binding Source={StaticResource InventoryView}}" IsSynchronizedWithCurrentItem="True" />
<local:CustomItemsControl ItemsSource="{Binding Source={StaticResource InventoryView}, Path=CurrentItem}" />
</StackPanel>

This is a good enough workaround for now.

I've been working hard on seemingly simple functionality. I have a usercontrol (derived from ItemsControl) which has a panel (the itemshost) and a few other things like so:

<ItemsControl x:Class="VisualizerUsercontrol.myVisualizer"
              x:Name="parentControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <ItemsControl.Style>
    <Style TargetType="{x:Type ItemsControl}">
      <Setter Property="Template">
        <Setter.Value>
          <ControlTemplate TargetType="{x:Type ItemsControl}">
            <StackPanel Orientation="Horizontal">
              <Button>press me</Button>
              <ScrollViewer VerticalScrollBarVisibility="Auto">
                <StackPanel Orientation="Horizontal"
                            IsItemsHost="True" />
              </ScrollViewer>
            </StackPanel>
          </ControlTemplate>
        </Setter.Value>
      </Setter>
    </Style>
  </ItemsControl.Style>
</ItemsControl>

When instantiating the control on a window, I bind it's ItemsSource to some other control, like a listbox's selectedItem. This of course, for a master-detail view. The bug is that this ItemsControl is unable to resolve it's ItemsSource, because the Element for which it is looking, is in another scope.

That actually is kind of unpleasant, and I hope to find a workaround for it. I appear not to be alone in this finding, and the consequences of it really limit the use of a usercontrol severely.

I've completely rewritten the RssBandit to Grazr converter, so that alphabetic order is used. That looks way nicer, doesn't it?

Program.cs (4.49 KB)

People that know me, know that I love Resharper. They now have a 2.0 version for Visual Studio 2005 and my bet is that I will love it as soon as I try it. But there was always one thing that I disliked about Resharper: the caching of the solution took ages on big projects.

Visual Studio 2005 gives us some refactoring tools and code snippets. Although they lack the power of Resharper, they will do for me. But what I can not live without is the fast code navigation that Resharper brought us. Their type navigator works instantly and that feels so incredibly smooth and silky, I just can't do without.
The last couple of months, I have used a new free tool that brings the instant navigation power without the caching costs. DPack has been pushed to the limits and performed incredibly.

Of course, I still miss a few Resharper features, such as 'find all references', which is light years ahead of the Visual Studio offering. But the speed of which my solutions now open does seem to make it up.

Try it, you might like it.