I'm using clrtype.py; trying to keep everything 100% IronPython. Here's the
Converter code:
import clr
from System import Object, Type
from System.Globalization import CultureInfo
from System.Windows import Thickness
from System.Windows.Data import IValueConverter
from System.Windows.Media import Colors
from Utilities import clrtype
class ColorToThicknessConverter(IValueConverter):
__metaclass__ = clrtype.ClrClass
_clrnamespace = "3screens.Converters"
@clrtype.accepts(Object, Type, Object, CultureInfo)
@clrtype.returns(Object)
def Convert(self, value, targetType, parameter, culture):
return None if value is None or value == Colors.Transparent or value.A
== 0x00 else Thickness(1)
@clrtype.accepts(Object, Type, Object, CultureInfo)
@clrtype.returns(Object)
def ConvertBack(self, value, targetType, parameter, culture):
pass
For this app, I have the need to draw a border around a DataGrid cell if the
specified background color is not null or transparent; thus the
ColorToThinknessConverter class. As I mentioned earlier, this converter (as
well as the other converters not ported yet) work in the C# version. I chose
this particular one, to test first, since it is relatively simple.
I also tried to Python-ize the C# code when porting; so the code may not be
structured the same, however it is functionally the same. In the Python
version of the Convert method though, I'm not sure if None translates 1:1 to
C#'s null. Or, if I should return something else like
DependencyProperty.UnsetValue. In any case, returning null in the C# version
works.
I placed the clrtype.py file in a Utilities module (directory with a non-empty
__init__.py file). In the console I can correctly see it working as a .NET
type:
pv> from Converters import ColorToThicknessConverter
=> None
py> c = ColorToThicknessConverter()
=> None
c.GetType()
=> <System.RuntimeType object at 0x000000000000002B
[3screens.Converters.ColorToThicknessConverter]>
app.xaml:
<?xml version="1.0"?>
<Application
xmlns="http://schemas.microsoft.com/client/2007";
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml";
xmlns:converters="clr-namespace:3screens.Converters"
x:Class="Microsoft.Scripting.Silverlight.DynamicApplication">
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary
Source="Resources/Brushes.xaml"/>
<!--<ResourceDictionary
Source="Resources/Converters.xaml"/>-->
<!--<ResourceDictionary
Source="Resources/Styles.xaml"/>-->
<!--<ResourceDictionary
Source="Resources/DataTemplates.xaml"/>-->
</ResourceDictionary.MergedDictionaries>
<converters:ColorToThicknessConverter
x:Key="ColorToThicknessConverter"/>
</ResourceDictionary>
</Application.Resources>
</Application>
Normally I keep all of my XAML resources in a "Resources" directory. I was
able to get my Brushes.xaml merged successfully this way. For the converters
though, I commented out my normal convention and placed the reference in
app.xaml to make debugging easier. Once it gets loaded correctly, I'll switch
back to Resources/Converters.xaml
app.py:
from System import Uri, UriKind
from System.Windows import Application
from System.Windows.Controls import UserControl
class App:
def __init__(self):
Application.LoadComponent(Application.Current, Uri("app.xaml",
UriKind.Relative))
root = Application.Current.LoadRootVisual(UserControl(),
"MainPage.xaml")
App()
Loading app.xaml fails with the aforementioned AG_E_PARSER_BAD_TYPE referring
to the position of the Converter reference in the app.xaml file.
Lastly, I'm doing all of this from a Mac. Incidentally, I replaced the server
script with my own script code:
server:
open /Applications/Safari.app "http://localhost:2060";
mono ../bin/Chiron.exe /d:$@ /w
I also made it executable via chmode +x, and call it via:
$ . server 3screens
It launches Safari on the default Chiron port, and starts Chiron using the
passed in directory.
If you can help with any of this, great. But, don't spend too much time on it,
as it's just an idle exercise I'm doing to see if I can do all of my
Silverlight development on my Mac using IronPython (or IronRuny).
Thanks.
On Jan 21, 2010, at 12:52 AM, Jimmy Schementi wrote:
> Are you using clrtype.py or a C# stub? If you're not using either of these,
> then you will get a AG_E_PARSER_BAD_TYPE when trying to tell XAML about your
> Python type, since the corresponding CLR type won't be found. If send your
> python and XAML code, then I can help you figure this out.
>
> ~Jimmy
>
>
> On Jan 20, 2010, at 8:32 PM, Edward J. Stembler wrote:
>>
>> I installed the Developer runtime, which incidentally is LinkID=150227 for
>> Mac. In any case, I got my Converter recognized as a .NET type; however I
>> couldn't get passed the AG_E_PARSER_BAD_TYPE error when loading the converter
>> reference in XAML. I initially thought there may be some namespace issue, but
>> I can see the Converter is reflecting it's correct namespace, and the XML
>> namespace seems to match too. I tried importing my converted in App.py
>> before the XAML is loaded to see if that would put it in scope, but that
>> didn't work either. I'm not sure what to try next? Anyone have any ideas?
>>
>>
>> On Jan 20, 2010, at 3:12 AM, Jimmy Schementi wrote:
>>
>>>> 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:
>>> http://go.microsoft.com/fwlink/?LinkID=150228
>>>
>>>> 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.
>>>
>>> ~Jimmy
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
