locked
System.ComponentModel.TypeConverter missing? RRS feed

  • Question

  • I'm attempting to port an existing silverlight library to Metro Xaml/C#, but it looks like System.ComponentModel.TypeConverterAttribute is missing. Is there a Metro XAML version of this attribute?
    Thursday, September 22, 2011 9:11 PM

Answers

  • No, there is no TypeConverterAttribute (or TypeConverter) in the current version.  Are you using the type converter for data binding or Xaml? 

    If you're using it for data binding, the workaround is to implement an IValueConverter. 

    If you're using it for Xaml attributes, the workaround is to make the type constructable.  E.g. replacing

    <Person Address="123 Main" />
    

    ... with

    <Person>
        <Person.Address>
            <Address House='123' Street='Main' />
        </Person.Address>
    </Person>
    

    • Marked as answer by JeroMiya Friday, September 23, 2011 9:12 PM
    Friday, September 23, 2011 8:26 PM

All replies

  • Let me investigate this one and get back with you.
    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    Friday, September 23, 2011 1:08 PM
    Moderator
  • One of our experts in this area will be replying to this thread with some answers.
    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    Friday, September 23, 2011 6:27 PM
    Moderator
  • No, there is no TypeConverterAttribute (or TypeConverter) in the current version.  Are you using the type converter for data binding or Xaml? 

    If you're using it for data binding, the workaround is to implement an IValueConverter. 

    If you're using it for Xaml attributes, the workaround is to make the type constructable.  E.g. replacing

    <Person Address="123 Main" />
    

    ... with

    <Person>
        <Person.Address>
            <Address House='123' Street='Main' />
        </Person.Address>
    </Person>
    

    • Marked as answer by JeroMiya Friday, September 23, 2011 9:12 PM
    Friday, September 23, 2011 8:26 PM
  • Mike,

    So there is no mechanism for a type to explicitly specify how it should be converted to other types? That is incredibly useful functionality that plays a big part in a lot of frameworks.

    (Obviously we have cast operators, but most frameworks don't use casts dynamically since the rules for binding to them are typically language specific.)


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Friday, September 23, 2011 9:35 PM
  • There's no new alternate mechanism for it.  But I agree it's useful and we are looking at this.  Thanks for commenting on it.

     

    Saturday, September 24, 2011 2:41 PM
  • I've been going through the code of Json.NET in the hope of porting it to WinRT but that library seems to hevily depend on the TypeConverterAttribute. Any news about this, is the a possibility that we will see it in the future?
    Saturday, March 3, 2012 11:07 AM
  • @mikoskinen - as Mike Hillberg points out above, there is no custom TypeConverter support for Metro

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Saturday, March 3, 2012 5:59 PM
  • No, there is no TypeConverterAttribute (or TypeConverter) in the current version.  Are you using the type converter for data binding or Xaml? 

    If you're using it for data binding, the workaround is to implement an IValueConverter. 

    If you're using it for Xaml attributes, the workaround is to make the type constructable.  E.g. replacing

    <Person Address="123 Main" />
    

    ... with

    <Person>
        <Person.Address>
            <Address House='123' Street='Main' />
        </Person.Address>
    </Person>
    


    There is no TypeConverterAttribute (or TypeConverter) in the Consumer Preview version. 

    hdolder

    Wednesday, March 7, 2012 7:32 AM
  • So there is no generic way for converting between types? TypeConverter is helpful because it allows the author of a type to provide intrinsic support for determining to/from which types a type may be converted and actually converting between types - most typically for converting to/from string but other types as well. This isn't just something used in xaml/binding (although those used typeconverters in wpf/sl) - this is often used in code as well (runtime serialization, calculation engines, etc.). Without some infrastructure in the WinRT framework itself for declaring an object that will perform these calculations and without a way to generically obtain that object to do the conversion every developer who needs this has to hand craft it themselves - 3rd party developers must allow for some means of providing a valueconverter and every developer must create a valueconverter for doing the conversion.

    Already you have a number of people asking about this:

    http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/506727b4-deae-4db9-b8de-1c9e4b746a6e

    http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/1640de5b-3715-4b44-b918-25ae1a437c5e

    http://social.msdn.microsoft.com/Forums/en-NZ/winappswithcsharp/thread/8ba5be4e-db65-4640-83ad-20c1b2a479d0

    Thursday, March 8, 2012 1:50 PM
  • Please consider adding type converters back in.  It makes for a lot of unnecessary extra code for our component library's end users when we can't use it.

    actiprosoftware.com - Professional WPF, Silverlight, and WinForms UI controls and components

    Friday, June 1, 2012 6:47 PM
  • Ok, RTM version is here and TypeConverters still absent. Can someone from MS share your plans about that? Are you going to add TypeConverters back, or no? If no, why?

    We ship the similar control sets for WPF, Silverlight and Windows Store. In SL and WPF it's possible to write something like SelectedDate="11/11/2012" in xaml, but in Windows Store Apps it fires unhandled exception. It would be hard to explain our customers why they can use it as is on other platforms, and should use IValueConverters in Windows Store.


    notacat

    Wednesday, September 12, 2012 5:16 PM
  • The ability to create custom TypeConverters will not be in this release.  We're not commenting on future plans, but are aware of this request.

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Wednesday, September 12, 2012 6:47 PM
  • thank you for the answer, at least we know for sure about this release.

    notacat

    Wednesday, September 12, 2012 7:21 PM
  • How about expanding the xaml parsing support to handle nullable types? It seems that right now you cannot have a nullable<int>, etc. type property and be able to set it in xaml. You get a runtime error that it "Failed to create a 'Windows.Foundation.IReference'1<Int32>' from the text '10'. Can this be addressed in a hotfix/service pack or is this something that would also have to wait for a future version?
    Tuesday, October 16, 2012 3:48 PM
  • The second approach only works if Address is a class. This approach doesn't work if Address were a struct since you get a compile time error that a struct cannot be constructed in xaml. Can't you expose some way for a custom type to support parsing from a string? Even if its something like a particular naming convention for a static method on the type and then when you construct the XamlTypeInfo you can look for an invoke that method from within the CreateFromString of the IXamlType you autogenerate.
    Wednesday, October 17, 2012 9:14 PM