if (_converter == null)
{
_converter = new DummyConverter();
}
return _converter;

part with the following code:

return _converter ?? (_converter = new DummyConverter());

The converter class in this example has no local fields (just methods), so it is very lightweight. Your argument about the class being instantiated repeatedly is valid, but the same thing is true about StaticResource, DynamicResource, etc, and we certainly don’t worry about the perf impacts with these (which are far more prevalent). As such, I’m okay with the overhead.

But thanks for keeping me honest! :-p

-dw

You call this a singleton and say that “the markup extension only creates the converter the first time ProvideValue is called”. That’s not quite accurate. Each time the markup extension is used, a new instance is going to be created, because, well, that’s how markup extensions work. What is true is that only one instance will ever be returned. Use this in a template where it will be used 1000 times, you’ll get 1001 instances constructed, but only 1 of those will not be very shortly garbage collected. It may have some impact on performance, but I doubt you’ll find a scenario where this impact is significant. It won’t have an impact on memory.

There’s a few alternate implementation ideas to consider. First, you might want to consider using a weak reference instead of a strong reference, just so the “singleton” instance isn’t held longer than it needs to be. If your converter is going to be configurable, you have a couple of choices. You can either cache multiple instances based on the values in the markup extension, or just “return this;” from the ProvideValue (knowing what this will mean to memory usage).

The {x:Static foo:MyConverter.Instance} alternative isn’t a bad idea, but only works for non-configurable converters, and is more verbose.

I found the pattern also most helpful when it comes to declaring custom commands – thanks for sharing

I published the complementing extension here ]]> http://drwpf.com/blog/2009/03/17/tips-and-tricks-making-value-converters-more-accessible-in-markup/comment-page-1/#comment-423 Dr. WPF Fri, 03 Apr 2009 01:36:44 +0000 http://drwpf.com/blog/?p=48#comment-423 Hi Eric,<br><br>In the example I included above, the converter is a singleton. The markup extension only creates the converter the first time ProvideValue is called and thereafter returns the same instance. Like you say, this works for most converters.<br><br>I, too, like AlanO's example, which takes my static instance approach and puts it in a base class for easy derivation.<br><br>I do have some examples of per-instance (nonshared) converters that cache object references for performance reasons. I may post an example of one such converter that I think might help others... I did not include it with this article because it requires carefully explaining the usage scenarios so that the same converter is not inadvertently shared across controls. I'll see what I can write up. :-) Hi Eric,

In the example I included above, the converter is a singleton. The markup extension only creates the converter the first time ProvideValue is called and thereafter returns the same instance. Like you say, this works for most converters.

I, too, like AlanO’s example, which takes my static instance approach and puts it in a base class for easy derivation.

I do have some examples of per-instance (nonshared) converters that cache object references for performance reasons. I may post an example of one such converter that I think might help others… I did not include it with this article because it requires carefully explaining the usage scenarios so that the same converter is not inadvertently shared across controls. I’ll see what I can write up.

I’m not sure how much overhead subclassing MarkupExtension is, but the bigger issue for me is that I’m also not sure if I would create a new Converter instance every time ProvideValue() is called — think creating 1000 of these as part of a template. Could put a lot of memory pressure on the app without realizing it, and without necessity — generally you only need one converter instance because it’s reused and does not need to be thread-safe.

I like AlanO’s static approach — best of both worlds.

For parameterizablility (is that even a word?), the MarkupExtension approach gives you more flexibility because you can create the instance inline as opposed to as a resource or as part of the codebehind. But these situations are rare in my experience.

Thank you so much for the great tip!

I extended it to save one extra step (because I am lazy too) by making an abstract generic class. This makes it easier to convert my existing ValueConverters to use your technique. Sample code follows:

// Base class
public abstract class ConverterMarkupExtension: MarkupExtension, IValueConverter
where T: class, new()
{
private static T m_converter = null;

public override object ProvideValue(IServiceProvider serviceProvider)
{
if (m_converter == null)
{
m_converter = new T();
}
return m_converter;
}

#region IValueConverter Members

public abstract object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture);
public abstract object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture);

#endregion
}

//Sample derived class
public class BytesToKBValueConverter: ConverterMarkupExtension
{
public override object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
if (value != null && value is double)
{
double bytes = System.Convert.ToDouble(value);
return bytes / 1024.0d;
}
else
return value;
}

public override object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
{
throw new NotSupportedException();
}
}

Do you mean for specifying the ConverterParameter or for supplying a parameter to the constructor of the converter? Both will work, but you’re pretty much stuck with supplying the parameter as a StaticResource (the same as you’d normally do for ConverterParameter) or you could leverage the ObjectReference markup extension I described a while back.

Cheers,
-dw