In Visual Studio, there are two places you can type expressions for evaluation – the Watch Window and the Immediate Window. The former, the Watch Window, is usually used for variables and has a nice hierarchical expansion system whereby you can ‘drill-down’ into the interior of an object.

But you can also use the Watch Window for more complicated expressions. Take for example, a humble Boolean variable, zz. If you just type it into the watch window, you will see this:

You can also (now in the latest Cylon) call a function like this:

The first example evaluates to a Boolean value, true, while the second gives the string representation of the Boolean “true”.

But the Watch Window has its limitations. You can’t recall a line that you typed in – and you are also limited in space. Enter the Immediate Window!

The Immediate Window is a full text window. It has command recall, you can move around in it using the cursor, and in general, it’s much more like a highly versatile scratch pad rather than the structured Watch Window.

In the Immediate Window, I can type arithmetic expressions like

(v + 3) * 4

and get the correct answer:

I can also do much more complicated things as well. To illustrate this, I’ve used an example from the book “Essential ActionScript 3.0” by Colin Moock. On p362, there’s a simple example of some XML code:

Now, I’m not an ActionScript programmer (I use C# mostly with excursions into various Assembly languages when required). One of the things about ActionScript that’s puzzled me was the use of the XML operators @ and .. and their various permutations. So I used the example to explore XML (and to check that the Cylon Expression Evaluator was doing its stuff).

In the Immediate Window (having stopped at a suitable breakpoint), I typed

novel.TITLE[0].toString()

and got

OK – that’s as expected. But there’s an ActionScript optimization: if there’s only one XML node in an XMLList, you can leave out the indexer:

novel.TITLE.toString()

Yes, that works too (with a bit of internal Cylon magic, I might add).

So, how about some attributes?

novel.@ISBN.toString()

also behaves as expected:

Lastly, here’s how descendant’s work. The example is slightly more complex - an XML structure have two books inside it:

Using the descendent operator, I can obtain this:

But there’s one thing I really like about ActionScript (and I wish C# would adopt something like this) – Regular Expressions are first class objects. My problem with Regular Expressions is that I can never, ever, remember the syntax sufficiently well to get the things to work first (or even second time...). With the Immediate Window, I can experiment using Regular Expression literals. For example, here’s one from Adobe’s web site (note the IntelliSense completion list generated when I typed the dot):

I want to use the test function to see if the string "Class-A" matches:

/Class-\w/.test(“Class-A”)

and I get the result:

Internally, the Cylon Expression Evaluator uses the same ANTLR LL(*) parser that generates the information for Amethyst’s coloring and IntelliSense system. It’s very satisfying when the IntelliSense system (which is generated in the Visual Studio IDE) meshes perfectly with the Cylon Expression Evaluator, which is linked to the IDE, but is actually independent. That’s one very odd feature of Visual Studio: the debugging system is by design a completely separate entity from the core IDE. I’m not sure why this is, and it certainly leads to some difficult problems in implementation. But when it all works, you really do get a truly great debugging system.

I’m sure that if you go to Microsoft’s Visual Studio web site, you can find out about all the whizzy new things that VS2010 does – trimming your toe nails automatically, and so on. Most of which I doubt I’ll ever use. However, internally things are different: VS2010 now uses WPF as the core technology for much of the display. Crucially, the core Text Editor is written in WPF and so has a completely new API that Visual Studio extension (VSIX) developers are expected to use.

So the good news is that the Text Editor has a whole set of new features (nicer fonts, scaling, line heights of different widths and so on). The bad news is that VSIX authors will have to rewrite their applications? Well, no. Fortunately, that’s not the case. The Visual Studio team has produced a good (actually, it’s excellent) ‘legacy’ Text Editor API interface which allows existing VS2008 extensions (that work with the old COM based ’core’ editor) to work seamlessly with the new WPF Text Editor.

Seamlessly? Almost so. anyway. It took me about two days to get Amethyst fully up and running with VS2010. Some of the work involved registry changes – VS2010 now has a different (and more logical) way of handling VSIX registry entries. Some involved fixing bugs in Amethyst which were only revealed when moving to VS2010. And there were one or two problems with the new Text Editor itself; with a product of this complexity it’s not really surprising.

But with a bit of pushing and shoving and a little bit of rewriting to deal with a couple of peculiarities of the Text Editor, it’s all now working: here’s the Amethyst Designer (a Flash application) embedded with the new Text Editor:

The appearance of Visual Studio 2010 is broadly familiar but is also slightly different. All the ’chrome’ - the frames, menus and so on around the document - are handled by the WPF, though some of the non text-based tool windows - such as the Solution Explorer - are still the same.

And here’s the new Text Editor working with MXML and embedded ActionScript:

You can see one of the new features of the Text Editor - font scaling. In the top split window, the font is the normal size, while in the bottom pane, I’ve set it to 150%.

The key question for me though is if we can target both VS2008 and VS2010 from the same code base and with the same build. When we ported our Ruby IDE, Ruby In Steel, from VS2005 to VS2008 we built the the project in VS2005 and ensured (with some tweaks) that it would run in VS2008. Microsoft say that this trick can be done with VS2010 - but the other way round. That is, you should be able to develop wholly in VS2010; and the same binaries will work with VS2008.

Ideally, I’d like to ensure that Amethyst works from the same installation with both VS2010 and VS2008. It should work - and we’re most of the way there. But I suspect there’s some detailed ’fit-and-finish’ work to do on the installation before we’re done.

These include:

 Styles displayed in the Designer
 ‘Go Live’ mode to activate controls and styles (as in a running application)
 Expanded style support includes colour pickers for setting solid colours or gradients
 ‘Code Behind’ now fully supported
 Flex projects auto-create ActionScript code-behind file for MXML documents
 User-defined Comments now supported

There have also been numerous fixes and enhancements throughout the editing and design environment. These are in addition to the features released in the January ‘edge’ edition which introduced enhanced debugging including our unique multi-process ‘listen-and-attach’ Cylon debugger for debugging multiple SWFs simultaneously.

Styles and ‘Live’ Design

Styles can be applied to a selected control or to the Application by making selections from the Styles palette:

To preview styles on controls right-click your application and select ‘Go Live’:

Now controls will respond to events such as mouse clicks and text entry via the keyboard. You can also test out dynamic styles such as rollovers which change in response to mouse events:

When you’ve finished, uncheck ‘Go live’ to continue in Design mode.

 For more information on Styles and ‘Go Live’ see: The Amethyst Flex ’Live’ Designer.

Code-Behind

By default, Amethyst now separates the design layer from the event-handling (ActionScript code) layer by creating a pair of linked MXML/ActionScript files. This provides a ‘code behind’ capability similar to that used in C# projects. Code-behind is not obligatory and scripts may, optionally, be entered into ‘script’ sections in MXML:

User-Defined Comments

You may define named comment-types which can be grouped or sorted in the Task pane of Visual Studio:

The Amethyst ‘edge’ releases include features which are still in development and are less thoroughly tested than the features of our full beta releases. The last full beta is still available as an option. For download details on the current edge release, please see the appropriate thread in the SapphireSteel Software forum. For information (and a download link) for the last full beta of Amethyst, Beta 7 go to: Amethyst Download Page.

You may either view the video above in low definition or (recommended) click the link to view it in High Definition (HD) on YouTube: HD Video On YouTube.

The HD version defaults to a size of 720 by 1280 and you can click buttons on the YouTube video bar to alter the size or expand the video to full screen.

For a full list of our YouTube videos on ActionScript, Flex, Ruby and Amethyst, refer to the index of SapphireSteel YouTube Tutorials.

You can watch the low definition video below or click this link to watch it in HD on YouTube:

 http://www.youtube.com/watch?v=_qyTxu_qpkk&hd=1

For a full list of our YouTube videos on ActionScript, Ruby and Amethyst, see the SapphireSteel Software YouTube Video Index.

Here’s the link: http://www.infoq.com/news/2010/02/ruby-in-steel-15.

Ruby In Steel ‘Developer Edition’ 1.5 provides integrated edit-and-run capabilities for Ruby 1.8.x, Ruby 1.9.x and JRuby 1.4 including IntelliSense and two integrated debuggers - Cylon for Ruby 1.8.x and the updated JCylon debugger for JRuby 1.4.

Ruby In Steel 1.5 supports named ‘Build Configurations’ to allow developers to test their applications against alternative Ruby interpreters simply by picking a configuration name from a drop-down list. This makes it easy to test an application against (for example) Ruby 1.8.6, Ruby 1.8.7, Ruby 1.9.1 and JRuby 1.4. The two integrated debuggers , Cylon and JCylon, support breakpoints, step-into/out/over and drill-down debugging (to expand complex variables) in multiple windows or in hovering ’debug tips’ in the code editor itself.

A free 60-day evaluation version of Ruby In Steel 1.5 is available for immediate download. Ruby In Steel 1.5 is a free update to existing registered users of any previous version of Ruby In Steel Developer.

More information:

 Overview of Ruby In Steel
 Ruby In Steel Feature List

There will be a few significant additions to the Amethyst Designer - our drag-and-drop user interface layout workplace - in the next edge release. The two most obvious of these are the addition of ‘styles’ and the first public release of the Amethyst ‘Go Live’ Design Mode.

You will be able to apply styles by making selections from the Styles palette (in the same tabbed window as the Properties palette):

This makes it a simple matter to transform a plain design like this...

Into a styled design like this...

Some styles, such text fonts and button rollover colours aren’t normally visible in the Designer. However, our new ‘Go Live’ mode actives the controls to let you interact with them just as you would in a running application. Just pick ‘Go Live’ from the right-click mouse menu...

And suddenly you can enter text, click radio buttons and test out rollovers...

When you’ve finished, disable ‘Go Live’ mode and you are back in the normal design mode so that you can carry on adding, moving, aligning and resizing controls until you are ready to ‘Go Live’ again to test them out...

I’ve recorded a short video to show styles and ;’Go Live’ in action. For best video quality, click the link below to watch it in High definition mode (or full screen) on You Tube:

http://www.youtube.com/watch?v=eJXx...

Alternatively, watch the low definition version below:

Yup, styles...

Up to now, the visual Designer has been restricted to the display of Properties. In the next version it will also let you add Styles such as colours, gradients, images, fonts, borders and drop shadows. You can even turn rectangular components into ovals by setting corner styles.

All you have to do is select the style from a palette in Visual Studio and enter the value you wish to apply or, when dealing with colours, use the pop-up colour picker. You will be able to set styles for individual controls or for the entire application. Watch for more news and tutorials here on the Blog.

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

    trace('hello world!')

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

Attach

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.