5

It doesn't look like TypeConverter is available to use. What is recommended to replace this?

I was going to go and create my own TypeConverter class to use to replace it, but if there is a new or better way in WinRT to do it, I'd go that route. There are also many other classes that I would need to recreate; like all the default type converters.

Josh Close
  • 22,935
  • 13
  • 92
  • 140
  • `TypeConverter` is actually a pretty complex API, especially when you consider all the upstream plumbing; For winrt, yes: it is pretty minimal - so: to answer you question we'd need to know what set of scenarios you need to support. – Marc Gravell Sep 19 '12 at 13:43
  • Converting a string to any built-in type and back to a string. This is where all the built-in converters, like `StringConverter`, will come into play. I'm also using `TypeDescriptor.GetConverter` and any other classes used around these. I could implement just the features from these I need by creating a "MissingFromRt45" set of classes, but it looks like the list of classes will be quite large. – Josh Close Sep 19 '12 at 13:57
  • Do you think it would be more beneficial to pull out all the `TypeConverter` stuff I'm using and change it to a custom type conversion setup? That way it will work no matter what version of .NET it's running on. – Josh Close Sep 19 '12 at 14:39
  • 1
    that would be my recommendation, yes. I feel your pain: I have libraries that work on CF, regular .NET, Silverlight, Portable, Xna, RT, etc. It can be a PITA. – Marc Gravell Sep 19 '12 at 15:34

2 Answers2

2

There is no TypeConverter class in the WinRT and the team has not announced any plans to include it in a future release. You have a number of options.

Option 1: If the conversion is to be done as part of a data binding use the IValueConverter interface as Dennis mentioned.

Option 2: If you are the creator of the type you can add your own explicit or implicit operators to support casting:

http://msdn.microsoft.com/en-US/library/xhbhezf4(v=vs.80).aspx

http://msdn.microsoft.com/en-US/library/z5z9kes2(v=vs.80).aspx

Option 3: You could create your own TypeConverter class.

Option 4: (The way I'd do it if not part of a binding) You can add your own extension methods:

static public class ConverterExtensions
{
    static public string ToFixedString(this double value)
    {
        return value.ToString("D");
    }
}

Which would let you write code like this:

double d = 123.45;
string str = d.ToFixedString(); // str now equals "123"
Jared Bienz - MSFT
  • 3,550
  • 17
  • 21
  • 1
    If the goal is to only replace the use of TypeConverter in XAML declarations, which of these options is preferable? I've tried #1 unsuccessfully, and #4 is out. – Jay Borseth Oct 13 '12 at 17:32
  • I would be really interested how you implement option 3. I can't find any typeconverter example in uwp. Also there exists a uservoice https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9576897-implement-system-componentmodel-typeconverter-in-w – Briefkasten Jun 01 '16 at 08:05
  • With the creators update typeconverters are coming! http://timheuer.com/blog/archive/2017/02/15/implement-type-converter-uwp-winrt-windows-10-xaml.aspx – Briefkasten Mar 19 '17 at 09:21
0

Use IValueConverter interface.

Dennis
  • 37,026
  • 10
  • 82
  • 150