Debugging multiple SWFs
One of the neat things about Microsoft’s ASP .NET and Visual Studio is that you can easily debug the ‘code behind’ an ASP page. You launch the page in a browser, set a breakpoint in the code and when the code executes, the breakpoint is hit and you can see what’s going on.
It occurred to me that this would be a highly useful thing to be able to do with Flash: when a web page with a Flash SWF embedded is launched it should be able to connect with Visual Studio and you should be able to debug it, just as if you had started by launching the SWF from the Visual Studio end.
This mechanism that allows you to debug a program that you didn’t launch from Visual Studio is called ‘attach’ – and the ability to attach from the web page is known as ‘auto-attach’. When auto attach is enabled, and a web page containing a debuggable SWF is loaded in a browser (or otherwise activated), the SWF sends a message “I’m here” to Visual Studio and Visual Studio replies with an “OK – please continue” message, both of which messages are invisible to the user. It’s only when the SWF encounters a breakpoint that something happens.
It’s taken me some time (and a lot of effort) to get to this point in our Flash Platform IDE, Amethyst. I first started thinking about this about a year ago, but it’s taken till now to get it working smoothly. I realized that first of all, I needed a complete, fresh, ’from the ground up’ implementation of the Adobe Virtual Machine (AVM) debugging protocol to do this, so I set about engineering one in C#. This is the ’Cylon Debugger’. The second part was integrating this into the Visual Studio debug system and in particular figuring out how to get attach and auto-attach to work.
We’ve been using this technique very successfully in house for some months now in debugging our Flex drag-and-drop design environment, The Amethyst Designer. For technical reasons concerned with Microsoft’s COM technology (most of Visual Studio is still written using COM), it isn’t possible to debug the Designer (an SWF application hosted in a COM container) in the same instance of Visual Studio that holds the Designer code (written in ActionScript).
So we’ve been using two instances of Visual Studio to debug the Designer. One instance holds the ActionScript code and builds the Designer while the other runs an Amethyst application that happens to use the Designer. The first application (containing the Designer code itself) is run in ‘Listen’ mode while the user runs the application which uses the Designer in the second instance of Visual Studio.
When a significant event occurs in the running instance of the Designer which is being used in the second application – when a button is moved or resized say - then the ‘listening’ Visual Studio (that’s the one containing the ActionScript code of the Designer) can intercept this via a breakpoint – and now we can use all the debugging features: Watch, Call Stack, Step-into etc. - to debug the Amethyst Designer as it is being used.
In my next Blog post, in a day or two, I’ll explain in detail exactly how we use Amethyst’s auto-attach to debug the Amethyst Designer so that you will be able to use the same tools to debug multiple SWFs simultaneously in your own Flash or Flex applications.
Auto-attach debugging is available in the current ’edge release’ of Amethyst.