’Live’ Flex Design - Amethyst update
The latest ’edge’ release of the Amethyst IDE (version 00.00.836) for the Adobe Flash Platform includes a number of new features in both the visual Designer and in the code editing environments.
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.
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:
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.
Hi, it’s really great to see the progress here even though I’m not currently using Amethyst. One thing that caught my eye - the code behind files. Are they linked to the MXML file using <Script source="" /> or do they use the technique used in ASP.NET Web Forms (inheritance)? Also, the name "Xyz.designer.as" suggests that the AS file is generated by the IDE which is not true in this case.
I’m looking forward to try the next beta when it’s available. Keep up the good work!
We’re constrained by the Flex MXML syntax here which requires a mx:Script source= "x.designer.as" tag for the mxmlc compiler to be able to generate the correct code.
When a new ’code- behind’ MXML file is created, we add the correct mx:Script syntax and, in addition, do the necessary magic in Visual Studio to get the "x.designer.as" file to look like it depends in the parent MXML file (which it does).
So the answer to your question is that it’s sort of half way to the ASP.NET (or C# Form Designer) way of doing things where there is no explicit dependence specified - it’s all done by the parent/child relation.
There are several advantages to using a parent/child relation even though it is sort of ’over specified’ by having to include the Script reference:
First, you can move the pair around as an entity from one folder to another say, and the logical relation is maintained without you having to do anything.
A second advantage is that it separates out the layout code (MXML) from the logic (ActionScript events, etc.) and makes the whole thing a heck of a lot cleaner and neater (especially for creating new events from the Properties Window or double clicking a control to generate the default event).
But we’ve also built in an ’escape clause’ where you can explictly attach/detach a dependent ActionScript file from it’s MXML parent and treat it as a normal ActionScript file in case you need to do something fancy or change your mind.
And as Huw says, we also support the old ’embedded’ CDATA ActionScript style.