KevLinDev Blog

This morning we released our first beta of Xamlon Pro - Flash Edition. This development suite allows you to develop xaml content targeted to the Flash Player. What I think is particularly cool is that you can now develop Flash not only using XAML markup but also with C# code-behind. Technically, you can use any .NET language, but we’ve only tested with C# internally.

Our current release includes the SWF compiler, cswf, which converts either standalone XAML into a SWF file, or it will combine XAML and a .NET assembly (consisting of any number of C# files) into a SWF file with ActionScript bytecode. We’ve also included C# hooks into the native Flash API. I think there are some huge advantages to what we’re doing here.

IntelliSense

Now, I’m not a big Flash developer, yet , but I’ve found Visual Studio’s IntelliSense something I couldn’t live without. It makes learning the Flash API incredibly easy. Fortunately, the names are clear enough that you get a good idea of what’s going on. Well, and there’s plenty of documentation on the API to find out the gory details. I’ve been able to go from concept to final working SWF file really quickly, especially considering I’ve never done any Flash development before.

Visual Studio with any .NET Language

Now, I realize some of you out there think OO+JS is a bad idea, but lets just say we differ on that point. Personally, I love OOP for large projects and most .NET languages give you that style of programming. That’s where I find a lot of power in offering the use of any .NET language to write your supporting Flash code. And, at the same time, you get to leverage all of the tried and true built-in and polished functionality that is offered in Visual Studio. I just don’t hear people raving about their Flash IDE for coding.

Type Safety

And with OOP, you get type safety. I spent a number of years writing large ECMAScript libraries and I found it invaluable to define clear interfaces for my objects. This is a weak form of type safety, but in reality, ECMAScript lets you pass in whatever you want. You really won’t know if you’ve passed in an object of incorrect “type” until you execute your code. And, from what I hear, you don’t have a nice ActionScript debugger available to you to figure out what broke and why. So, that’s where type safety can step in and help. And believe me, this becomes more and more important as your projects grow.

We actually compile your C# code to a full .NET assembly. That means that if you pass in the wrong type into a method or try to set a property with the wrong type, your code won’t compile. You might even have latent errors of this type in your code that don’t appear until release (it always shows up after you release). With our approach, you catch the trouble at compile time which is far better than catching it later in the development cycle. I think type safety is a huge plus and will save hours and hours of debugging time for the Flash coder.

Anyway, I think we have another really exciting product with our Flash Edition, so please feel free to give it a try.

We’ve been working our butts off at Xamlon for months now and it’s great to get to share some of the fruit of our labor. Last week, we released our second beta of Xamlon Pro - Compact Edition which allows you to develop xaml content for the .NET Compact Framework. One of our “big” editions is the support for Vector Graphics.

The Compact Framework’s version of GDI+ is quite limited. For example, strokes cannot be larger than one pixel wide. So, we’ve written our own 2D rendering engine for that platform. The current support is a bit limited, mainly due to limited processor strength; however, we currently handle solid brushes, opacity, linear gradients with two stops, radial gradients with two stops, all Avalon pen properties except dash-related properties, all 2D primitives (Point, Rect, Matrix, Transform, etc.), and all Shapes (Arcs, Béziers, Lines, Ellipses, etc.).

On the markup side, we were able to bring our full XAML parser over to the CF. We rely heavily on TypeConverters to convert the attribute string values to CLR types. Unfortunately, these don’t appear to exist on the Compact Framework, so we had to recreate that mechanism. It’s all working great and it’s just so cool to be able to take a XAML file and view the same results on the desktop, on Pocket PC/Window CE, and now in the Flash viewer (more on that later).

The current Longhorn documentation does not indicate what happens when a StrokeDashArray has an odd number of entries. It seems the typical solution is to repeat all entries once to end up with an even number of entries. For example, this is what the SVG specification indicates to do in that case and after a few tests in LH4074, it appears this is the case in Avalon too. However, I noticed that StrokeDashArray properties that contain only one number result in no stroke being display. If I repeat the number, then the stroke appears as expected. So, I’m not sure if this is a bug, but at the very least, the behavior is inconsistent.