[IronPython] Are Converters (IValueConverter) supported in IronPython + Silverlight?

Jimmy Schementi Jimmy.Schementi at microsoft.com
Wed Jan 20 09:12:02 CET 2010

> I took a simple converter and ported it to IronPython, however 
> I'm getting the ever helpful SystemError 2255. 

Do you have the Silverlight "Developer" runtime? The "Consumer" runtime give you only error codes, while the developer runtime gives you actual exception messages. Here's the developer runtime:

> I can manually import my converter class via the REPL, and do a dir on it too.
>  Which leads me to believe there's another issue I'm unaware of.  
> Perhaps it's not supported?  Has anyone else tried implementing a 
> converter in IronPython yet?

IValueConverter is an interface that allows you to make custom data conversions that happen during data binding in XAML: http://msdn.microsoft.com/en-us/library/system.windows.data.ivalueconverter(VS.95).aspx. However, IronPython doesn't directly support data binding in Silverlight, since Python classes are not 1-to-1 with CLR classes. The XAML required to hook up a converter (Converter={StaticResource FormatConverter}) won't be able to find a FormatConverter class defined in IronPython either, since the name is auto-generated. So, you'll be able to interact with your Python classes from the REPL, but they will fail to be used in XAML (if you use the developer runtime you'll probably see an error in the XAML parser ... which unfortunately also gives cryptic error msgs =P)

There are two ways to wire this up: 

(1) Use clrtype.py to control the CLR type, properties, etc, that the IronPython class generates. Lukáš Čenovský recently showed that you can do data-binding with this in Silverlight: http://gui-at.blogspot.com/2009/11/inotifypropertychanged-and-databinding.html

(2) Have anything your XAML needs to reference as a C# stub (defining all things requiring static references, including properties and methods), which your Python class inherits from and defines the actual behavior.

I suggest #1 as it's a more elegant solution, but #2 will work as a good safety net if you encounter something that doesn't work in #1.


More information about the Ironpython-users mailing list