Wpf built in value converters

If you want to databind two properties that have incompatible types, you need a piece of code in between, that converts the value from source to target type and back.

This piece of code is called ValueConverter. A value converter is a class, that implements the simple interface IValueConverter with the two methods object Convert object value and object ConvertBack object value. WPF already provides a few value converts, but you will soon need to implement your own converts. This is a common naming for value converters. Make it public and implement the IValueConverter interface. That's all you need to do.

First thing you need to do is to map the namespace of your converter to a XAML namespace. Then you can create an instance of a value converter in the resources of the view and give it a name. If you want to use a normal ValueConverter in XAML, you have to add an instance of it to the resources and reference it by using a key. This is cumbersome, because and the key is typically just the name of the converter.

A simple and cool trick is to derive value converters from MarkupExtension. Even passing a culture in the surrounding XAML setting Language or xml:lang to the sl-SI culture, an example of a culture that uses a comma for decimal in this way does not solve the issue.

To be usable as a TypeConverter implementation that supports XAML, the ConvertFrom method for that converter must accept a string as the value parameter. If the string was in valid format, and can be converted by the TypeConverter implementation, then the returned object must support a cast to the type expected by the property.

Otherwise, the ConvertFrom implementation must return null. Each TypeConverter implementation can have its own interpretation of what constitutes a valid string for a conversion, and can also use or ignore the type description or culture contexts passed as parameters.

However, the WPF XAML processing might not pass values to the type description context in all cases, and also might not pass culture based on xml:lang. These characters are reserved as the entry and exit for a markup extension sequence.

ConvertTo is potentially used for serialization support. Serialization support through ConvertTo for your custom type and its type converter is not an absolute requirement. However, if you are implementing a control, or using serialization of as part of the features or design of your class, you should implement ConvertTo.

To be usable as a TypeConverter implementation that supports XAML, the ConvertTo method for that converter must accept an instance of the type or a value being supported as the value parameter. When the destinationType parameter is the type String , then the returned object must be able to be cast as String. The returned string must represent a serialized value of value. Ideally, the serialization format you choose should be capable of generating the same value if that string were passed to the ConvertFrom implementation of the same converter, without significant loss of information.

If the value cannot be serialized, or the converter does not support serialization, the ConvertTo implementation must return null , and is permitted to throw an exception in this case.

But if you do throw exceptions, you should report the inability to use that conversion as part of your CanConvertTo implementation so that the best practice of checking with CanConvertTo first to avoid exceptions is supported. If destinationType parameter is not of type String , you can choose your own converter handling. Typically, you would revert to base implementation handling, which in the basemost ConvertTo raises a specific exception. Your CanConvertTo implementation should return true for destinationType of type String , and otherwise defer to the base implementation.

Your CanConvertFrom implementation should return true for sourceType of type String , and otherwise defer to the base implementation. In order for your custom type converter to be used as the acting type converter for a custom class by a XAML processor, you must apply the TypeConverterAttribute to your class definition. The ConverterTypeName that you specify through the attribute must be the type name of your custom type converter.

With this attribute applied, when a XAML processor handles values where the property type uses your custom class type, it can input strings and return object instances.

You can also provide a type converter on a per-property basis. The type of the property must match the type that is processed by your custom type converter.

With this attribute applied, when a XAML processor handles values of that property, it can process input strings and return object instances.

The per-property type converter technique is particularly useful if you choose to use a property type from Microsoft. NET Framework or from some other library where you cannot control the class definition and cannot apply a TypeConverterAttribute there. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Converters in WPF. Kailash Chandra Behera Updated date May 16, Introduction This article explains and demonstrates a little bit about WPF converters.

It explains the types of converters available in WPF and the uses of them. The object that emits the data is called the source and the object that accepts the data is called the target. Value Converters. A Value Converter is required when a target is bound with one source, For instance you have a text box and a button control. You want to enable or disable the button control when the text of text box is filled or null.