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.

Ouch, this really got to me. I upgraded to the May CTP, hacked my application to compile again and ran it.

The first screen of the application let's you choose a person to load. That went fine. But when loading more of this persons data on a following screen, Indigo completely freezes. That puzzled me quite a bit. Everything worked fine with the Feb. CTP, and I had not expected serialization problems. Wcf has a way of not throwing exceptions with serialization problems so I did not really have much to go on. I was retrieving a collection with about 14 objects in it. When I deleted a few objects everything went smooth again! So something new with maximum message size was going on?

The solution was not to up the maximum size (it was high enough), but to loosen the reader Quota's for my service.
A reader Quota is defined as: 'Gets or sets constraints on the complexity of SOAP messages that can be processed by endpoints configured with this binding'. The constraints include items such as a maximum element depth, a maximum length for string content within the message. The constraints protect against a class of denial of service (DOS) attacks that attempt to use message complexity to tie up endpoint processing resources.

There you have it. I guess they lowered the defaults.
<readerQuotas maxDepth="90000" maxStringContentLength="90000"
            maxArrayLength="90000" maxBytesPerRead="90000"
            maxNameTableCharCount="90000" />

That helped me for some time, but recently I've had to go higher again. Possibly the Wcf team could set the defaults to much higher values!

I've stumbled upon Grazr, which I really like (for now). It's a different way of viewing your blogroll in opml 1.1 format. It's snappy, cool and very web 2.0 like.

However, it's quite an ordeal to use something like opmlmanager or blogrolling to manager your opml file, while, let's face it.. you already have setup in your precious rss reader. I use the excellent RssBandit and I obviously just want to export my feeds (including categories) as opml and read it into Grazr. Well, it seems that the Grazr api is very strict about opml and only accepts version 1.1. RssBandit exports to a totally different schema (1.0) and conversion is needed. I found a converter by Matthew Hazlett for the native rssbandit format to opml 1.0. I adjusted it to use the opml 1.0 exports of rssbandit and spew out valid opml 1.1 files. The result can be seen on the right side of my site. I will categorize my feeds soon, for your viewing pleasure. I hope you like it.

There was one weird caveat though: when converted by xmlWriter with an encoding of utf-8, there would be a byte order mark that Grazr does not except. I've had to choose ascii encoding to get around this. If there are people that are going to use the converter and feel a strong need for utf, I will do an update and use the bytewriter to delete those pesky 3 bytes. My guess though that Grazr will lighten up and start accepting pretty soon.

My name is Ruurd Boeke and I am owner of the dutch company Sitechno. We do consultancy and hardcore development in .Net on enterprise applications, from client to server.

Categories I will post in are: winfx, or-mapping, mainstream .net and methodologies, with the occasional mad-man ranting in between.

I hope I'll be able to keep your attention.

With that, I declare this blog opened.