Multi-Process Flash Debugging
In my last Blog post I mentioned the new ability of the ’Cylon’ Debugger for Amethyst to attach to multiple processes to allow the Flash or Flex developer to debug multiple SWFs simultaneously. In this Blog post, I’ll go into a little more detail...
This is a feature which will allow Flash or Flex programmers to debug complex applications comprising multiple SWF files all at the same time. In fact, you could even simultaneously debug completely separate applications running in different browsers.
We use this feature ourselves when programming the Amethyst Designer (the Flex drag-and-drop user interface creator which we have seamlessly embedded into Visual Studio) and most of the examples in the screenshots below show us debugging the Designer. But, in principle, we could be debugging any Flash, Flex or AIR applications.
First of all, you can see that I’ve selected a different command from the normal ‘Start Debugging’ command. This is the ‘Listen’ command. When you select this, Visual Studio doesn’t actually launch the SWF in a browser as the normal ‘Start Debugging’ command does. Instead, it activates the Cylon debugger in ‘listen’ mode where it is listening for a startup message from an SWF. Visual Studio is now in debug mode: you can’t edit files, for example, and if you look the Debug menu, you’ll see that the ‘Stop Debugging’ command is enabled. The only real visible indication that something unusual is happening can been seen in the Amethyst Console:
...where a message indicating that the Cylon has been activated can be seen. By the way, the Amethyst Console is also used to display trace messages from ActionScript, so when you say...
...the text “hello world” will appear in the Amethyst Console tool window. I then start my test program and switch from Code to Design. This loads the Designer SWF which has been compiled with ‘-debug=true’ and the Designer SWF connects to the ‘listening’ Visual Studio which then stops when the breakpoint (in the Designer code) has been hit. The test program is halted at initialization:
...while the Designer code is breakpointed:
So, to summarize, this what I’ve done. I’ve started to debug an external program (here the Amethyst Designer SWF) which was launched externally – here by another copy of Visual Studio – by setting the Cylon debugger into listen mode.
There’s one other thing to note about the Watch window – IntelliSense! With Cylon, you can type ‘x.’ in a Visual Studio Watch window and get the correct completion list for the object under inspection.
Of course, you also get the usual hierarchical breakdown of objects, separated out into ‘base’, ‘Non-public members’ and ‘Static members’ (just like C#). I’ve also added two ‘viewers’ for XML data and strings (again like C#).
Now, so far we’ve got one external SWF debugging in Visual Studio. What happens if another comes along? Assume that I’ve started another SWF via a browser (Firefox or IE – both will work fine). The first thing that you’ll notice is – nothing! The browser will hang – and the reason it’s hanging is that it’s waiting for the go ahead from Visual Studio/Cylon. So start up the Attach to Process... dialog from the Debug menu in Visual Studio and from the Transport drop down combo, pick ‘Cylon’:
Then from the ‘Qualifier’ drop down, pick ‘Adobe Flash Player’. You’ll now see a list of processes that are either ‘attached’ (greyed out) or ‘awaiting manual attach’:
Select a process and click the ‘Attach’ button:
Now if you redisplay the ‘Attach to Process...’ dialog, you’ll see that the SWF process name is set and it’s ‘title’ is ‘attached’. Finally, if you look under Debug | Windows | Processes, you’ll see a list of all attached processes:
At last – Auto-attach!
The whole procedure of using the ‘Attach to Process...’ dialog would be quite time-consuming and tedious if you repeatedly had to do it for every web page, say. So I’ve added an ‘auto-attach’ mechanism that does it all for you. If you select the ‘Auto Attach’ option (it’s actually a toggle) from the Debug menu, then when a debug-enabled SWF starts up, it will be attached and run just as if you had done it manually.
Here’s the result for three activations of the same SWF embedded in a HTML page:
All three SWFs have breakpointed at the same location (they are the same SWF, but running in separate browsers) and if you step, you’ll see the yellow arrow move from process to process as the breakpoint is handled.
Flesh programmers eh. Where do they teach that? :)
Seriously, thanks for developing Amethyst. I look forward to using it in production. Also, I’m looking forward to the day when Silverlight will have this good an IDE.