SapphireSteel Software: The Blog
the blog

Announcing Amethyst 2.0

by SapphireSteel Software
ActionScript and Flash, 2nd generation IDE
Sunday 2 December 2012.

SapphireSteel Software is pleased to announce the successor to Amethyst 1, our professional IDE for Flash and ActionScript development.

Amethyst 2.0, which will be launched early in 2013, will provide a unique range of powerful Flash development tools hosted within Visual Studio 2012 or 2010. Major new features include:

- A new ‘bubble’-based debugger to navigated debugged code in linked popup windows
- A profiler to find inefficient code and monitor memory usage and leaks
- A unique ‘scratchpad’ where you can store notes and code fragments for easy re-use
- Document Outliner to view and find methods and variables using a hierarchical tree
- Powerful new ‘find all references’ tool that lets you smart-filter and store your code searches
- Semantic error detection to track down potential problems using on-the-fly code analysis
- Improved support for iOS and Android (both emulators and real devices)
- Call Graphs – integrated tools to trace method calls and relationships
- Obfuscator – to stop people decompiling your SWFs into easily readable ActionScript
- Conditional compilation – capabilities that go way beyond the ActionScript standards
- FlashForms – to drag, drop and design form-based applications in pure Flash

From today, if you buy Amethyst 1.0 (for just $299), you will automatically be entitled to a free upgrade to Amethyst 2.0 [1] when it is released.

Be sure to keep an eye on this blog. We’ll be giving much more information on the features of Amethyst 2.0 in the weeks ahead.

Bookmark and Share   Keywords:  Amethyst 2  news

WiX in Visual Studio 2012

by Dermot Hogan
Monday 29 October 2012.

One of the consequences of the release of Visual Studio 2012 has been the demise of the Visual Studio Setup and Deployment project (vdproj). To be honest vdproj was never that great and I can’t say that I mourn its passing. But something has to replace it and the free InstallShield Express wasn’t capable of building the installations that I require.

We’ve been working on the next versions of Amethyst and Sapphire (Ruby in Steel) for some time now, and one of the jobs was to make sure that both worked with the new version of Visual Studio 2012. Mostly this has been straightforward with none of the labour required when moving from Visual Studio 2008 to Visual Studio 2010, when Microsoft introduced a new core text editor (that was hard work!). The main problem has been the requirement to find a replacement for vdproj that works with both Visual studio 2010 and Visual Studo 2012.

So after a bit of searching, I came across WiX (Windows Installer XML) available here. WiX uses a declarative XML based syntax to describe the installation and you then use the WIX toolset to construct an MSI file, which you install in the normal way. WiX is widely used inside Microsoft itself, and with the 3.6 release is stable and well integrated into Visual Studio 2012. Oh, and it’s free.

The problem I was faced with was a pretty complicated vdproj installation file – services had to be installed, DLLs loaded into the GAC with a messy set of over 100 registry settings plus a good number of files that had to be scatted over the target disk. On top of that, there were non-trivial installation ‘actions’, such as configuring manifest files, searching for SDKs and the like.

There were two approaches to the problem. The first would have been to start from scratch and build the WiX file by hand. The second, which I chose, was to use a tool to convert the vdproj file to WiX format. For the second option, there were two routes. One would have been to use Dark (all WiX tools have terrible punning names like Candle, Burn and so on) which takes an MSI file and spits out WiX XML. Wonderful! Until you look at the resulting XML – it is completely incomprehensible. It’s very like looking at C code produced from disassembling a native EXE file. My guess is that Dark is unusable for the purpose I wanted except for the simplest of MSI files. Another route was to use my favourite all-purpose parser ANTLR to analyse the vdproj fle and spit out WiX XML. And that’s the route I chose.

The first thing to do was to look at the structure of the vdproj file. This isn’t documented by Microsoft, but it isn’t too difficult to figure out what’s going on and to construct an ANTLR parser for it. The parser produces an internal parse tree as normal, but the next step is something that I’d never tried before. Instead of just analysing the tree and generating IntelliSense for an internal data base, I needed to output real, solid XML.

The parse tree generated by using ANTLR to scan the Amethyst vdproj file.

So again, after a bit of searching and thinking, I turned to ANTLR ’string templates’, something I’ve never used before. A string template sort of does the opposite to the ANTLR parser: given a parse tree, you can traverse it and match ‘templates’ to the tree elements. When an element matches, the corresponding string template is invoked and spits out a piece of text, in this case WiX XML. Here’s a small sample that outputs a WiX file command:

file_unit(component_id, file_id, sourcepath, targetname, gac, folder_id, guid) ::= <<
<DirectoryRef Id="$folder_id$">
 <Component Id="$component_id$" Guid="$guid$">
   <File Id="_$file_id$" Source="$sourcepath$" KeyPath="yes"$if(gac)$ Assembly=".net"$endif$ Checksum="yes"/>

The template ‘payload’ is between the ‘<<’ and the ‘>>’ delimiters and it’s declared as a ’function’ that can be called from an ANTLR tree grammar. The ’function’s parameters like ’folder_id’ are substituted into the template body between ’$’ tokens’ (by default the token is ’<’, but ’$’ was more suibtable for XML). The template is invoked from the ANTLR tree grammar like this:

@init {string folderName; VdpToken t; bool inGAC; string targetName; string componentID; Guid g; string folderID;}
 : ^(FILE_UNIT id=STRING sp=STRING tn=STRING f=STRING sc=scatter_unit?) {
 t = f.Token as VdpToken;
 folderID = t.ID;

 folderName = _folders[folderID];
 t = id.Token as VdpToken;
 componentID = t.ID;
 switch (folderName) {
 case "ProgramFilesFolder":
 case "PersonalFolder":
 case "SystemFolder":
   folderID = folderName;
 inGAC = folderName == "GAC";
 if ((sc!=null?((CommonTree)sc.Start):default(CommonTree)) != null) {
   targetName = (sc!=null?sc.dllName:default(string));
 } else {
   targetName = ((VdpToken)(tn.Token)).ID;
 _sequence += 1;
 g = Guid.NewGuid();
 _components.Add(componentID, _sequence);
} -> file_unit(component_id={componentID}, file_id={_sequence}, sourcepath={((VdpToken)($sp.Token)).ID}, targetname={targetName}, gac={inGAC}, folder_id={folderID}, guid={g})

You can see that I’m mixing C# code and ANTLR tree grammar to invoke the ‘file_unit’ template which actually does the work of generating the WiX XML. The C# code builds up the arguments for the ’function call’ to the template. This might look a bit messy, and it did take me a little while to get the hang of ANTLR string templates, especially the conditional syntax, but it’s still, I think, faster than building the output by constructing the output file piece by piece in a program. And once the grammar and template exist, they can be modified simply.

The result is a fully functional WiX file, integrated into Visual Studio 20102 (and Visual Studio 2010). Here’s a snippet generated by the above ‘file’ string template: Looking back, I suspect that it would have taken me just about as long to construct the WiX file by hand as to do it using ANTLR and string templates. But I now have a new tool – ANTLR string templates - in my programming armoury. I think that will prove very useful in the future.

Bookmark and Share   Keywords:  development  sapphire  Visual Studio

Using the Team Server changeset as a software revision number

by Dermot Hogan
The numbers game
Sunday 6 May 2012.

There’s one thing that’s bugged me almost from the time I started using Microsoft’s Team Server source control system – how to get some sort of build or revision number incorporated automatically into the software. Strangely, there isn’t a simple way of doing this but there are several techniques described that you can find if you search for the subject. However, all the ones I could find referred to getting the build number when you are building on the server as part of an automated build.

I don’t use automated builds. Instead, I check the code out from the server and then build it on my own workstation. Also, the key piece of information is, for me, the ‘changeset’ number - not the build number. That’s what I use to identify a particular revision of the software when it is released.

To do this, I needed to do three things: first, write an MSBuild task that generated a small file with the changeset number in it, secondly, to invoke this task in order to create the changeset file when building and, thirdly, to remove the changeset file from source control.

The MSBuild task looks like this:

using System;
using System.IO;
using System.Text;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.VersionControl.Client;

namespace Sapphire.Steel {

public class BuildChangesetTask : Task {

private TaskLoggingHelper _tlh;

// the server URL
private string _server;
public string Server {set { _server = value; }}

// the file containing the changeset number
private string _fileName;
public string FileName {set { _fileName = value; }}

public BuildChangesetTask() {_tlh = this.Log;}

public override bool Execute() {
 TfsTeamProjectCollection tpc;
 VersionControlServer vcs;
 int changesetNumber;
 StreamWriter sw;
 StreamReader sr;
 bool result;
 StringBuilder sb;
 string oldText;
 string newText;

 try {
   sb = new StringBuilder(1000);
   _tlh.LogMessage(MessageImportance.Normal, "Connecting to '{0}'",_server);
   tpc = new TfsTeamProjectCollection(new Uri(_server));
   vcs = tpc.GetService<VersionControlServer>();
   changesetNumber = vcs.GetLatestChangesetId();
   if (File.Exists(_fileName)) {
     sr = new StreamReader(_fileName);
     oldText = sr.ReadToEnd();
     _tlh.LogMessage(MessageImportance.Normal, "Reading '{0}'", _fileName);
   } else {
     oldText = String.Empty;
   sb.AppendLine("namespace Sapphire.Steel.Project {");
   sb.AppendLine("\tpublic partial class ProjectPackage {");
   sb.AppendFormat("\t\tpublic const int CHANGESET = {0};\r\n", changesetNumber);
   newText = sb.ToString();
   if (oldText != newText) {
     _tlh.LogMessage(MessageImportance.Normal, "Updating '{0}' to changeset {1}", _fileName, changesetNumber);
     sw = new StreamWriter(_fileName);
   } else {
     _tlh.LogMessage(MessageImportance.Normal, "Changeset {0} has not been altered", changesetNumber);
 } catch (Exception ex) {
   _tlh.LogMessage(MessageImportance.Normal, "Failed: changeset number has not been updated ('{0}')", ex.Message);
 return true;


The key bit in the ‘Execute’ part of the task is this

tpc = new TfsTeamProjectCollection(new Uri(_server));
vcs = tpc.GetService<VersionControlServer>();
changesetNumber = vcs.GetLatestChangesetId();

which gets the changeset number from the server specified. This is then written it into the changeset file if it is different from the one that is already there.

The next part is to incorporate this MSBuild into the build process. So in my main build file I inserted a line immediately after the ‘Project’ line:

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="">
 <UsingTask TaskName="Sapphire.Steel.BuildChangesetTask" AssemblyFile="..\BuildChangesetTask\bin\Debug\BuildChangesetTask.dll" />

and I invoke it by using the BeforeBuild target:

<!-- targets -->
 <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.Targets" />
 <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\VSSDK\Microsoft.VsSDK.targets" />
 <Target Name="BeforeBuild">
   <BuildChangesetTask Server="http://server1:8080/tfs/steel" FileName="Changeset.cs" />

The final step is to exclude the changeset file - just use ’Exclude from Source Control menu.

Bookmark and Share   Keywords:  Visual Studio

AIR namespaces

by Dermot Hogan
The problems of numbers...
Tuesday 13 March 2012.

Recently, Adobe seem to have had a habit of changing the namespace used in the AIR descriptor file faster than we can create updates to Amethyst. With an AIR application, you don’t actually run the SWF directly. Instead, you use the ’AIR Debug Launcher’ or adl to to the job. This takes as its input an application descriptor file - an XML file that tells adl all about the SWF that it’s going to run.

The problem is that the namespace needs to match the version of AIR and in the last few months Adobe have been through 2.5, 2.6, 2.7, 3.0 and now 3.1 with 3.2 on the horizon. This means that when you create an AIR application using the Amethyst project creator, you are likely to use the wrong namespace and your AIR application won’t run.

Here, I’ve changed the namespace version to 3.1 which is correct for AIR 3.1.

But when something like this happens, the error messages aren’t very helpful. In fact, they are non-existent. The reason for this is that Amethyst launches adl as a separate process, and while it is possible for us to grab any error messages from the adl process and display them, it’s both complicated and has several downsides and so we don’t do that. In any case, it’s rarely needed since all the debug information comes via TCP/IP and this is handled very well by Amethyst.

But if you do get into a situation where you need to find out what adl is doing before it establishes the TCP/IP link, there’s a trick you can use. When you run an AIR program from Visual Studio, Amethyst displays the command it is going to use in the Output Window

All you need to do is copy the line starting with the double quote, open a command prompt and paste the line into it. Press RETURN and your AIR application will be launched. And if it isn’t you’ll see an error message. The bad news is that it’s going to be an Adobe error message which may leave you little the wiser as to what’s going wrong!

Bookmark and Share   Keywords:  Amethyst

Adobe Flash is dead? I think not!

by Huw Collingbourne
Never mind the confusing messages from Adobe. Our message is clear and simple
Wednesday 4 January 2012.

Adobe has managed to cause huge amounts of confusion about the future of Flash and Flex in recent months. It all began with their announcement, in November, of the ‘elimination’ of around 750 employees, and the “Shifting resources to support even greater investment in HTML5”. Combined with their decision to ‘contribute’ their Flash Platform framework, Flex, to Open Source (it’s now been looked after by Apache), it is unsurprising that the news was widely reported that: Flash Is Officially Dead.

Anyone who works with Flash knows that just isn’t true. There are huge numbers of Flash developers, Flash is just as ubiquitous today as it was before Adobe’s November announcement and, what’s more, Adobe has said quite clearly that they aim to focus “Flash resources on delivering the most advanced PC web experiences, including gaming and premium video, as well as mobile apps.” But then again, if Adobe is so committed to Flash, how come they will taking the extraordinary step of removing the visual designer from their Flash Builder IDE? I’ll have a few comments on that later. For now, though, I want to tell you a bit about our plans for Amethyst, the SapphireSteel Software Flash Platform IDE. I’ll try to make sure our messages are as clear and simple as possible.

The Future of Amethyst

We are 100% committed to the continued development of Amethyst to support ActionScript development for Flash and for Flex. We will continue to support, develop and extend our visual design tools. Later in the year we will launch Amethyst 2 which (among other things) will include a unique bubble-based debugging environment (in addition to the traditional debugger), a built-in profiler, an obfuscator and dramatic improvements to features such as the call-graph, refactoring, code analysis and code navigation.

Amethyst 2

Let me say this again: Amethyst 2 will support Flex. Amethyst 2 will support Flash (including integration with Flash CS 4, CS5.x etc.). Amethyst 2 will support all normal types of ActionScript development.

If you are already a user of Amethyst 1.x, there will be a low-cost upgrade path. If you buy Amethyst 1.5 any time in 2012, we guarantee that you will not lose out when you upgrade to Amethyst 2. Your upgrade cost will no more than the difference in price between the version 1.5 and version 2.0 product. We are completely and totally committed to Amethyst. No ifs, no buts.

But Isn’t Flash Dead…?

OK, now let me return to the confused messages coming from Adobe. In my view, the real confusion derives from the rather messy history of the Flex framework. Flex provides an extended class library for Flash. However, for reasons which I never understood, Flex was not made the ‘default’ library for Flash and it has never been (easily) available to users of the Flash IDE – CS4, CS5 etc. Instead, Flash developers were encouraged to move to another IDE. Adobe’s Flex IDE was called Flex Builder. Rather late in the day, Adobe seemed to realise that the naming of the IDE only reinforced the idea that Flex and Flash were completely different things. To try to hammer home the message that they were closely related, Adobe renamed their IDE to Flash Builder. Meanwhile, instead of talking about Flash and Flex, as they had in the past, they now began talking about ‘The Flash Platform’ as though it was all one, neatly integrated thing. Which, of course, it wasn’t.

Adobe then spent ages trying to rewrite Flex 3 and create Flex 4. In my view, they never fully succeeded. Flex 4 was released as a sort of hybrid that supported stuff from Flex 3 (including various components that had not yet been ‘migrated’ to Flex 4) as well as a whole batch of completely new stuff. In order to get the old stuff to work with the new stuff, a lot of not terribly elegant fixes were done. This ended up by creating a framework in which the components couldn’t even agree on what was meant by a ‘parent’ or a ‘child’. Believe me, that fact alone has caused me personally a lot of headaches. When we had to rewrite the Amethyst Designer to support Flex 4, each control that the user dragged and dropped onto an interface had to query its parents and children in order to determine whether they were from Flex 3 or Flex 4 and then decide how to interact with them. Making the wrong choice can crash the program. If you are interested, you can read more about this problem in an article I wrote for Flash and Flex Developer’s Magazine. The language I used in that article was a good deal more polite than the language I used in real life. Suffice to say, I have, er, ‘some significant reservations’ (this is me being polite again!) about Flex 4.

At any rate, having spent time trying to blur the boundaries between Flash (the Flash player, its programming language and libraries) and Flex (an additional set of classes aimed, principally, at data-driven development), it is not at all surprising that when Adobe pulled the plug on Flex, many people presumed they were pulling the plug on Flash too. Well, that’s not the case and Adobe has tried to get the message across that it isn’t the case. But still many people now think that it is the case.

A lack of Flex-appeal?

If you’ve found the Adobe announcements confusing, this is my take on it: Flex is an extended framework for creating data-driven applications using a Flash front end. The Flex framework has never been as successful as Adobe hoped so they’ve offloaded it for other people to look after. HTML 5 should be able to do most of the form-based data-centric things that Flex was targeting anyway, so Flex’s raison d’etre may not be raison enough.

Having dumped Flex, there is not much incentive now for Adobe to commit resources to the Flex IDE, Flash Builder, which explains why they have stated that the design view will not be developed in future. Flash, however, remains important to Adobe. Flash is everywhere on the Internet and many of the most successful games (check out Facebook) are implemented in Flash. Moreover, Adobe has a whole bunch of graphics, animation and web development tools that continue to make good money out of Flash developers.

Amethyst 2

Amethyst 2 – You Ain’t Seen Nothing Yet!

OK, the question is: so how does this affect Amethyst? Answer: not at all. Amethyst supports all types of Flash Platform programming. If you want to use Flex, that’s fine. If you don’t, that’s fine too. Amethyst has the best debugging and refactoring tools available for ActionScript. Unlike Flash Builder, Amethyst’s visual design environment is not being deprecated. On the contrary, we are actively developing it to add an even broader range of features. The same goes for the debugger. The Amethyst ActionScript debugger already boasts numerous unique features: you can use the current version to debug multiple SWFs simultaneously, to debug between ActionScript and C# in a single session, to hover and drill-down into complex objects right inside the code editor, to set simple and conditional breakpoints, navigate the call-stack and much more besides.

As for our new debugger (the one that we’ll be releasing in Amethyst 2 later in the year) – prepare to be blown away!

Bookmark and Share   Keywords:  Amethyst  Flash  Flex  ide

Amethyst 2 Sneak Peek

by Huw Collingbourne
A taste of things to come...
Monday 2 January 2012.

We have some exciting things in development for Flash Platform programmers.

Here is a first look at Amethyst 2. What you see here is one of our new debugging features. Suffice to say, while Amethyst 1.5 has (in our opinion!) by far the best ActionScript debugger currently available, you ain’t seen nothing yet!

We’ll be releasing the first public beta of Amethyst 2 soon. Be sure to keep an eye on this blog for more details. When Amethyst 2 launches, reduced price upgrades will be available for Amethyst 1.x users. What’s more, we guarantee that anyone who buys Amethyst 1.5 now (at any date during 2012) will be able to upgrade to Amethyst 2 for no more than the price difference between Amethyst 1.5 and Amethyst 2. So don’t wait. If you are not already an Amethyst user, make the switch today and you’ll be offered an exclusive low-cost upgrade to Amethyst 2 later this year!

Bookmark and Share   Keywords:  Amethyst  development  news

Create a Ruby On Rails Blog in Visual Studio

by Huw Collingbourne
New video tutorial
Friday 18 November 2011.

Yes, it’s the classic tutorial pared down to its basics.

We’ve just uploaded a video to show how to create a simple Ruby On Rails blog in under five minutes. The video itself is a bit longer than that since we couldn’t resist taking the opportunity to show off the Ruby In Steel ’Cylon’ debugger. Even so, this shows you how to go from start to finish in less time than it takes to make a cup of coffee. And not a command prompt in sight! :-)

Bookmark and Share   Keywords:  Ruby In Steel 2  tutorial

Installing Amethyst for Adobe Flash or Flex

by Huw Collingbourne
Tutorial and guide
Friday 30 September 2011.

While Amethyst itself is simple to install, you may need some ’prerequisites’ to support Flash or Flex development.

We have just added a new Installation Guide to guide you through the process of installing everything from a free edition of Visual Studio (if you need one) to the Java runtime and Flash Debug Player necessary to support Flex or Flash development.

Bookmark and Share   Keywords:  Amethyst  tutorial

ActionScript IntelliSense in Visual Studio

by Huw Collingbourne
New tutorial
Tuesday 20 September 2011.

I’ve just recorded this short tutorial on some of the essential features of Amethyst’s IntelliSense for ActionScript and MXML.

For more videos, see the Amethyst Tutorial Library.

Bookmark and Share   Keywords:  Amethyst  IntelliSense  tutorial

Adobe CS5 and Visual Studio - sharing projects

by Huw Collingbourne
Design in Flash, Debug in Amethyst
Friday 9 September 2011.

I’ve just uploaded a short video to show two ways of sharing Flash/ActionScript projects between the Adobe Flash IDE (CS4, CS5 and later) and Amethyst...

Bookmark and Share   Keywords:  Amethyst  tutorial

More Blog Posts...

0 | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 |...


© SapphireSteel Software 2014