KevLinDev Blog

I’m mainly posting this so I’ll have a reference for myself, although other SVG’ers may find this helpful. I seem to be rebuilding machines and installing new VM’s at a fair pace lately. The machines running XP get SP2 installed and, unfortunately, that limits and breaks some of my local SVG development. So, here’s what I’m doing to get things “back to normal.”

The first annoyance I ran into was that I was unable to double-click local SVG files and have them display properly in IE6. OK, they would display properly, but I had to go through multiple clicks and dialogs to view the content. Very annoying, to say the least. Anyway, the message in IE appeared to be a pop-up block, but even after I disabled Pop-up blocker (I prefer Google’s toolbar for that for now), the problem persisted. The trick turned out to be in Tools->Options under the Advanced tab. Simply turn on “Allow active content to run in files on My Computer” and that problem goes away.

The next problem was with debugging. I was pleasantly surprised years ago to find out that I could debug my SVG ECMAScript in Visual Studio as long as I was viewing my SVG files in ASV and I was using IE’s script engine. After SP2, that feature went away. A special thanks goes out to Doug Schepers for this fix. Basically, you need to go to the following registry key:

    [HKEY_CURRENT_USER\Software\Microsoft\Windows Script\Settings]

and add/set:

    ”JITDebug”=dword:00000001

From there, you should be in business.

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).