Hello, allow me to highlight the Xamlon forum post titled "How far will you go to support Flash".
Tomas writes: I've been following Xamlon and cs2swf for some time now and had a few questions regarding UI controls and C# events/properties. 1) As I recall, the event and UI control classes in cs2swf were modeled after the native as2 "class" objects. Since the windows forms and compact version of XAML run against the .NET Windows.Forms control objects, how will Xamlon eventually bring these two worlds together? 2) Will XAML built w/ the Pro Windows.Forms edition be interchangable with the Flash XAML compiler? (including the UI object's methods, properties, and events) 3) Will the Xamlon compiler enable coding of Flash Applications via a "flash compact" .NET Framework? This would imply that a limited subset of .NET Framework namespaces/API beyond UI (such as: sockets, reflection, data structures, and XML classes) could be brought in from existing C# source and executed in the Flash Player VM. Look forward to your thoughts. And Robin Debreuil from team Xamlon responds: Those are certainly the hard questions : ). 1) We have started on two sets of controls, modeled after Avalon and WinForms controls. While I think the Avalon controls will eventually be the better ones, there are pretty big reason to go winform right now. We also have the compact framework for Xamlon, so I think the logical first target will be for that (in that the Flash player can't really support the fuller set of Winform components, just due to sheer size as well as some things that just can't be mapped, like threading etc). Down the road though, the Avalon 'thinking' works better for markup imo... that would also need to be a subset of course, but a very functional one. 2) It should be interchangeable with at least the compact version, though there will probably be some 'notes' people should read : ). There are some things with swf that don't map 100% and they become very difficult to support bit for bit. One example, even lower than the component level, is Enumerate doesn't guarantee the order in swf. Generally the objects are backwards so we reverse them, but there are cases when things are deleted or added out of order, resulting in an order that isn't the same as in C#. We can build our own sets here to get the 1% case, but sometimes you will take a pretty big hit on speed and size everywhere (going away from swf' native array implementation for example) only to solve a really uncommon case. There are other things that just don't map at all, so while there should be 'interchangeability', that would require using a defined subset. We are thinking of marking assemblies like you do with [ClsCompliant] now, so [SwfCompliant] would at least let you know what isn't going to work. That isn't going to happen in time for the beta though.. 3) We do have all the swf api mapped with a SwfNative library, so everything programmatic you can do in Flash you can do in this. Then there are mapping routines for things like the BCL -- delegates, IEnumerator, string.Concat etc, which use SwfNative to build helper routines. So once we (or others) get deeper into components, we have all the tools needed to map things. But -- there will of course always be a trade offs when the mapping isn't so clean. As an example, we have swf XmlScokets available, the jist of them is the same, but the implementation is fairly different. So we can either map the simple things easily, map everything and end up with code that is larger and slower, or people could just use the XmlSockets, maybe with #if defs, for more exact control over the swf. Regex is an example of a class where this becomes even more torturous, where the purpose of regex (fast and small) kind of gets lost in the translation. So our goal is to map things, but there are places where this will run up against reality too... Source: http://www.xamlon.com/forums/shwmessage.aspx?ForumID=14&MessageID=816 What's your take? Do you think team Xamlon is onto something with the XAML to Flash conversion? - Gerald ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ xul-talk mailing list xul-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xul-talk
