Why does my IMultiBindingConverter get an array of strings when used to set TextBox.Text?

Question

Hi-

I'm trying to use a MultiBinding with a converter where the child elements also have a converter.

The XAML looks like so:

<TextBlock>
<TextBlock.Text>
    <MultiBinding Converter="{StaticResource localizedMessageConverter}" ConverterParameter="{x:Static res:Resources.RecordsFound}" >
        <Binding Converter="{StaticResource localizedMessageParameterConverter}" ConverterParameter="ALIAS" Path="Alias" Mode="OneWay" />
        <Binding Converter="{StaticResource localizedMessageParameterConverter}" ConverterParameter="COUNT" Path="Count" Mode="OneWay" />
    </MultiBinding>
</TextBlock.Text>

The problem I'm facing here is, whenever this is used with a TextBlock to specify the Text property, my IMultiValueConverter implementation gets an object collection of strings instead of the class returned by the IValueConverter. It seems that the ToString() method is called on the result of the inner converter and passed to the IMultiValueConverter. If used to specify the Content property of Label, all is well.

It seems to me that the framework is assuming that the return type will be string, but why? I can see this for the MultiBinding since it should yield a result that is compatible with TextBlock.Text, but why would this also be the case for the Bindings inside a MultiBinding?

If I remove the converter from the inner Binding elements, the native types are returned. In my case string and int.

Answer 1

Probably the targetType parameter of your localizedMessageParameterConverter converter is System.String. This is because the target type of the Bindings is inherited from the MultiBinding, and the targetType of the MultiBinding is System.String because TextBlock.Text is a string property.

See the following article for a similar problem: Multi-Value Converters, Value Converters and the Case of the Wrong Target Type

According to Microsoft Connect, this has been fixed in WPF 4.0. See: Microsoft Connect

The above article also explains a workaround.