stage.width will return the width of the content on the stage and ignore any empty pixels around the edges. So if you only have a 100 px wide rectangle on stage, your stage.width will be 100.

stage.stageWidth will give you the size of the stage, more like Stage.width in Actionscript 2. Use stage.stageWidth if you’re trying to position elements relative to the stage.

Same goes for stage.height and stage.stageHeight.

Given that the new motion tween creates a bezier path, I’m guessing that we’ll have access to creating such a path with JSFL. Which led me to think about creating that path in real-time, similar to the real-time drawing that I’d seen from ScribbleBot on Chris’s blog. Instead of scribbling a line in real-time, I’d be sketching a motion path. There would be a variable to determine “smoothness” so that it doesn’t create an unmananageable amount of new motion keyframes. And it could probably be done with a custom tool rather than a panel, so that the sketching could be done directly on the stage.

That also leads me to wonder if there’s a way to record the armature animation in real-time and convert it to a motion tween, similar to the feature that already exists in After Effects CS3.

I know, I’m a nerd. The first idea there became MotionSketch. I haven’t yet found a way to accomplish the second idea with the armature, but I have a few ideas.

Prior to the release of Flash CS4, I had gotten a little hooked on creating Flash extensions. It’s quite easy to create a classic motion tween with JSFL (Flash Javascript), you can simply make the following call: timeline.createMotionTween(). It was likely that createMotionTween() would remain for legacy support even though the name of the tween had changed from “motion” to “classic.” I’d seen all of the great new motion features demonstrated online, and I expected there might be an equivalent call for a new motion tween. When Lee Brimelow linked to the CS4 documentation, I went right to the Extending Flash section to see what had been added. I didn’t see any additions for the motion features, but I had also previously seen Lee’s post on Flash Camp in San Francisco. Fortunately, I live close to San Francisco and I decided to head over try out the application early, and maybe get a chance to talk with some of the Flash team about any undocumented features.

While at Flash Camp, I spoke with Richard Galvan and he directed me to John Mayhew, the engineer behind the new motion model in Flash. John was very affable and willing to follow up with me, but he didn’t know of any undocumented features offhand. Unfortunately, adding features to the JSFL API is usually somewhat of an afterthought because so much of the development time is spent on the new features themselves. I had a few ideas to use the new 3D features while at Flash Camp as well, but they were similarly left out of the JSFL API.

So I let those ideas go for awhile and focused on a different extension as my Flash Camp project. A few weeks later, I got a little antsy and I starting digging around in the Flash configuration directory for clues. I noticed two files in the Javascript directory named MotionXML.jsfl and MotionClipboard.xml. I started looking around in the JSFL file for undocumented commands that I could use, but to little avail. I think I even put some trace calls into the JSFL to spit out info when copying motion from the Flash IDE. I noticed that even though copying and pasting a new motion tween appeared to work the same way in the Flash interface as copying and pasting a classic tween, a new motion tween was not triggering the calls in the JSFL file. Looking at the XML file, I found that even though copying a motion tween wasn’t using the same JSFL calls, it was saving XML to the same file…just different XML. The classic tweens were generating XML with a root tag of <Motion> and the new tweens were generating a root tag of <AnimationCore>.

Flash seemed to be able to discern which type of motion it was copying or pasting and acting accordingly. So it occurred to me that I could grab the data from the motion clipboard and alter it before pasting it back. Additionally, if I wanted data from an existing tween, I could run a Copy Motion command, available to JSFL as of Flash CS3 thanks to Robert Penner’s Copy Motion feature, then go about altering and pasting. These are the extensions that I’ve created thus far using that very technique:

• EaseCaddy
• MotionSketch
• MotionBlur

Below is a rundown of the steps I used in the extensions mentioned above. This technique can be used in lieu of the non-existent timeline.createMotionObjectTween() command. I refer to this as a “hack” because it’s an unsupported method, but given the complexity of what can be created with this new motion model, editing the XML is actually a fairly efficient way to go about creating/editing a tween. If the XML is not properly formed, it can cause Flash to crash when you try to paste the motion, or it can create some funky bugs in the Motion Editor. Be sure to test your code thoroughly before releasing anything for public consumption. The language is JSFL (used to automate and manipulate the Flash authoring environment). There’s a link to documentation for the AnimationCore XML listed in step 3.

Step 1: Store the motion clipboard so you can restore it when you’re done. In some cases, I store it as a file. In this example, I store it as a variable.

var MOTION_CLIPBOARD = fl.configURI + "Javascript/MotionClipboard.xml";
var tl = fl.getDocumentDOM().getTimeline();
var storedMotion = FLfile.read(MOTION_CLIPBOARD);

Step 2(a): Copy motion to clipboard, retrieve the new clipboard contents and convert to XML. Use this step if you want alter an existing motion tween. The MotionBlur extension uses this step.

tl.copyMotion();
var xmlstr = FLfile.read(MOTION_CLIPBOARD);
var motionXML = new XML(xmlstr)

Step 2(b): Instead of copying the motion, you can create a new tween by loading a more or less blank motion XML template and adding content to it. The MotionSketch extension uses this step.

Step 3: The motion XML can then be altered using E4X. This portion of the code is different for each extension, depending on what the extension is trying to accomplish. Here’s the documentation on CS4 Motion XML that Flash engineer John Mayhew graciously put together.

Step 4: Write the altered XML to the motion clipboard.

FLfile.write(MOTION_CLIPBOARD, motionXML.toXMLString());

Step 5: Paste the altered motion.

tl.pasteMotion();

Step 6: Restore the motion clipboard for the user.

FLfile.write(MOTION_CLIPBOARD, storedMotion);

If you want to know if a motion tween has already been applied, you can retrieve the tweenType property from the current frame. A classic tween will return a value of “motion” and a new motion tween will return a value of “motion object“. If you use Step 2(a), you’ll want to check and make sure you have a “motion object” selected before proceeding.

And there you have it.

There are other ways to go about this process. You could, since motion presets are just motion XML files, run this process through the Motion Presets panel’s JSFL calls, but this would require more steps than the process laid out above.

You can now package Illustrator, InDesign, Photoshop, InCopy, and Bridge scripts and SWF panels (yes, most of these apps can have SWF panels now!) as Extension Manager packages. Flash, Fireworks, and Dreamweaver have worked with Extension Manager for years (since they all used to be Macromedia products). Extension Manager comes free with any Adobe CS4 application, so CS4 users will already have it installed. So far, I haven’t noticed Adobe making a big deal about this, but this is a great new capability for Adobe users and developers.

You may have noticed Extension Manager extension (.mxp) files showing up on my blog for Illustrator and InDesign scripts:

• Merge Text Extension for Adobe Illustrator
• Send Colors from InDesign and Illustrator to Flash
• Merge TextFrames Extension for Adobe InDesign

There are several advantages to using Extension Manager to install Extendscripts:

• Easy install: no complicated, cross-platform installation instructions needed
• Easy uninstall
• Version control
• Extensions can also be disabled without uninstalling
• A central location for extension instructions and credits
• Built-in license agreement

Packaging an extension can seem daunting, but it’s a fairly simple process to put one together. Especially if you’re already somewhat familiar XML files. There are two main components in packaging an extension:

• MXI (XML) file
• source files

The MXI file is just an XML file with information about your extension, its author, (optional) license agreement information, and where to install the necessary files. You can also find complete details on the MXI file format.

Don’t fret if you’re not familiar with XML. It’s a fairly readable text format, similar to HTML. XML differs in that it doesn’t have a restricted set of tags like HTML (tags are what appear between less than “<” and great than “>” brackets– e.g., <body> is an HTML tag).

Lee Brimelow has a great video tutorial on creating a SWF Panel extension in Flash. If you skip ahead to about 19 minutes in, you’ll see an example of an MXI file and how to create the MXP package using Extension Manager. You can also download his sample files from this page as well. This tutorial is what got me started making extensions.

Additionally, these two tutorials also have great step-by-step examples on how to populate an MXI file:

• Adobe – Developer Center : Creating and packaging a professional JSFL command
• Adobe – Developer Center : Creating an MXP Texture Extension for Fireworks

There are also tools that help you put together MXI files like this Flash panel: MXI file creator.

One thing you’ll notice inside an MXI file is the <files> node. This node lists all of the files that will be installed to the user’s computer. The <files> node will contain individual <file> nodes which have a source attribute and a destination attribute.

<files>
<file source="Queasy Tools.swf" destination="$flash/WindowSWF" />
</files>

If your source files are in the same folder as your MXI file, you simply have assign the filenames of those files to your source attributes. The destination attribute is where much of the power of an MXI file is found, because it can contain special, platform-independent keywords. Each application has its own set of keywords. The keywords begin with a dollar sign ($) character ($flash in the example above refers to the Flash Configuration directory). A complete list of keywords for any of the enabled applications can be found in their respective XManConfig.xml file.

Here’s the Illustrator CS4 config from my system (Applications/Adobe Illustrator CS4/Configuration/XManConfig.xml):

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<VariableForExMan>
<Data key="UserExtensionFolder">$InstallFolder/Configuration/Extensions</Data>
<Data key="$illustrator">$InstallFolder</Data>
<Data key="$plugin">$InstallFolder/Plug-ins.localized</Data>
<Data key="$scripting">$InstallFolder/Scripting.localized</Data>
<Data key="$presets">$InstallFolder/Presets.localized</Data>
<Data key="DisplayName">Illustrator CS4</Data>
<Data key="ProductName">Illustrator</Data>
<Data key="ProductVersion">14.0</Data>
<Data key="IconPath">Configuration/ai_exman_24x24.png</Data>
<Data key="SupportedInSuite">CS4</Data>
<Data key="DefaultLocale">en_US</Data>
<Data key="EmStorePath">$SharedRibsDataFolder/Adobe/Extension Manager2/Illustrator CS4</Data>
</VariableForExMan>
</Configuration>

One thing that hasn’t quite been perfected in CS4 is that, in some cases, a keyword takes you to a directory which has language/region-specific sub-directories. For example, if I take the $presets keyword from the Illustrator config file above for my destination attribute, in order to install a script in the proper location on my machine, the complete path would look like this:

destination=”$presets/en_us/Scripts”
(these strings are case-insensitive in an MXI file)

The problem here, is that a user who didn’t install the US English version of Illustrator won’t be able to install this version of my extension. So it’s not perfect…yet…but still very useful, and I’m confident that Adobe will resolve this in CS5.

Once you’ve finished creating your MXI file, and you’ve got your scripts and/or SWFs that you want to package, you can create your extension. To create an MXP file, all you have to do is double-click your MXI file and Extension Manager will open, package the extension, and prompt you on where you’d like to save it. Your extension is now ready to distribute.

I’m a Firefox user, so I went looking for an add-on that would do the same thing in Firefox. While it’s not quite as organized (i.e., it isn’t structured in a tree menu like the Activity Window), the “generate” tab of livehttpheaders is a pretty close substitution.

Originally found on What Do I Know.

UPDATE:  As Tim notes below, Firebug also has this capability. It’s under the ‘net’ section of the Firebug window. You have to choose to enable this feature before you see anything.

var codeString = "function myFunction() {";
codeString += "var myVar = 10;";
codeString += "for(var i=0; i < myVar; i++){";
codeString += " var newVar = i;";
codeString += "}";
codeString += "}";
sendStringToOtherLanguage(codeString);

While this is more readable than one string of text, it’s still a pain to edit. All code highlighting is lost. On top of that, you’re debugging across languages, so it slows testing even more. While working on a script recently I discovered a workflow that allows me to maintain code readability while working across multiple Adobe applications.

The solution came to me after discovering the toSource() javascript method.

You can download the example script in its entirety here.

This can be run from any Extendscript-enabled application (Illustrator, InDesign, Photoshop, Soundbooth, After Effects, or Bridge) and sent to any other application available to BridgeTalk (Contribute, Fireworks, Acrobat, Dreamweaver, Flash, Acrobat, etc).

You can set the source application by putting the script in the appropriate directory and running the script directly from the application or use the Extendscript Toolkit and select the application name from the drop-down at the top.

The breakdown is as follows…

I set the target application. In this case I’m targeting JSFL in Flash:

var targAppName = "Flash";
var sourceApp = BridgeTalk.getDisplayName(BridgeTalk.appName);
var targApp = getTargetAppName(targAppName);
var targAppStatus = BridgeTalk.getStatus(targApp);
var layerName = "layer created from " + sourceApp;

The following function is referenced above. It uses the targAppName variable to search for any open version of that application. It checks more recent versions of the application first. So if you have Flash CS4 and Flash CS3 open, it will find and return Flash CS4.

function getTargetAppName(nameStr){
//assumes higher versions are listed last
nameStr = nameStr.toLowerCase();
for(var i=apps.length-1; i>0; i--) {
if(apps[i].toLowerCase().indexOf(nameStr) != -1) {
if(BridgeTalk.getStatus(apps[i]) == "IDLE"
|| BridgeTalk.getStatus(apps[i]) == "BUSY"
|| BridgeTalk.getStatus(apps[i]) == "PUMPING"
&& BridgeTalk.getStatus(apps[i]) != "ISNOTRUNNING"){
//this version of the app is open
return apps[i];
}
}
}
return nameStr;
}

The stringifyFunction() function below takes a reference to another function, converts that function’s contents to a string using the toSource() method. The string returned from toSource() is encapsulated in parentheses, so those are removed before the string is returned.

function stringifyFunction(func){
var str = func.toSource();
var rStr = str.substring(1, str.length-1) + "\r";
return rStr;
}

The runTargetFunction is where I reference my JSFL functions (just one in this example). Instead of typing out each line of the function and appending it to a string I can call my stringifyFunction() method and pass my JSFL function (listed further down). Then I append my call to said function as a string, newLayer() in this case, and send it to my target application (Flash) using BridgeTalk. I also have some error checking with alerts to make sure the application is running and available.

function runTargetFunction(layerName){
if(targAppStatus == "IDLE"){
var bt = new BridgeTalk();
bt.target = targApp;
var scriptStr = stringifyFunction(newLayer);
scriptStr += "newLayer('" + layerName + "');";
bt.body = scriptStr;
bt.send();
BridgeTalk.bringToFront(targApp);
}
else if (targAppStatus == "ISNOTRUNNING" || targAppStatus == "ISNOTINSTALLED"){
alert(targAppName + " must be running for this script to work."); }
else if(targAppStatus == "BUSY" ) {
alert(targAppName + " is currently busy. Check the application to make sure no dialog boxes are open."); }
else { alert("There was an error when trying to interface with the " + targAppName + " application."); }

}

Next I run the function:

runTargetFunction(layerName);

Below my Extendscript functions, I list my JSFL functions just as if they were Extendscript. The Extendscript Toolkit is pretty forgiving and doesn’t mind that I have functions in different javascript dialects, so long as I don’t call the function directly from Extendscript. This script below is JSFL code that creates a new layer in Flash. If you have Flash open, but don’t have a document open, the script will open a new Flash document before creating the layer.

function newLayer(layerName) {
if(fl.documents.length < 1) fl.createDocument();
var layer = fl.getDocumentDOM().getTimeline().addNewLayer(layerName);
}

The layer created in Flash will list the application that sent the code. So if you ran this script from Photoshop CS3, the layer would be titled, “layer created from Photoshop CS3.”

I purposely wrote this example so that it would be easy to use with other applications. If you want to target a different application, change the functions at the bottom to work in another application (like Dreamweaver or Fireworks) using the application’s native JS and update the targAppName at the top. Keep in mind that communicating to most of these applications will only work in CS3 and later (post Adobe and Macromedia merger).

You can then write as many functions as you like for your target application and they’ll still be readable (just make sure to add them and call them in the string within runTargetFunction).

—
BREAKING NEWS (12/6/08): I noticed that the new Kuler extension for Flash CS4 has an “add to swatches” button, and it actually adds swatches to the swatches panel. After some decompiling and a lot of detective work, I found an undocumented JSFL call that was added to CS4. The feature is undocumented for a reason: it sends encoded XML data, and if the data is faulty, it crashes Flash. I have a few test cases working and I’m confident that I can add it to this extension, so the swatches will go right in the Flash swatches panel, rather than onto the stage, though it will only work in CS4. Be on the lookout for an update in the next few days.

UPDATE (12/7/08): Updated to version 1.1.0. If you have Flash CS4, the swatches will now go right into your Flash Swatches panel. Hooray!
—

There does seem to be a lot usefulness to such an extension, since XFL creates a new workflow between InDesign and Flash, and the Illustrator importer for Flash is fantastic, but neither one loads any of the swatches from the original document. I’ve certainly spent my fair share of time opening up the swatch properties, making sure the swatch is RGB or hex and copying all three fields one at a time.

So, I decided to plow ahead and see what I could come up with. The results are below. This extension takes the swatches from your current InDesign or Illustrator document and sends them to a new layer on the Flash stage. You can then use the eyedropper to pick up the colors, or you can add them to your swatches panel individually (similar to this demo of the Kuler panel).
UPDATE (12/7/08): If you have Flash CS4, you can skip the step above. Version 1.1.0 of this extension will send the Illustrator or InDesign swatches right to your swatches panel in Flash.

This extension will transfer spot and process colors of all varieties (RGB, CMYK, LAB, HSB). Rather than converting the CMYK with my own function, I used the applications themselves to convert the colors to RGB for Flash, so the transfer fidelity is quite good. It will ignore gradients, tints, patterns and fancy stuff like that. If you want to get your gradients into Flash see the bonus tip below.

InDesign to Flash CS4

Or, here’s what InDesign to Flash CS3 would look like.

Illustrator to Flash CS4

Or, here’s what Illustrator to Flash CS3 would look like.

Downloads and more below the fold.

Downloads

• Send Swatches to Flash.jsx (CS3, CS4)
• Send Swatches to Flash (ID).mxp (CS4)
  
• Send Swatches to Flash (AI).mxp (CS4-US only)

Installation

JSX file:

1. Place the JSX file into the appropriate directory:

InDesign CS3/CS4 > {application directory**}/Scripts/Scripts Panel
Illustrator CS3 >  {application directory**}/Presets/Scripts
Illustrator CS4 >  {application directory**}/Presets/{language/region}/Scripts

**Application Directories:
Windows > C:\Program Files\Adobe\{application name + version}\
Mac OS X > Applications/{application name + version}/

MXP file (CS4 only):

1. Double-click on the MXP file to install using Adobe Extension Manager CS4.

Usage

InDesign: make sure the scripts panel is open, Windows > Automation > Scripts, locate the Send Swatches to Flash.jsx script and double-click to run the script. If you installed the script using the MXP file, the script with be in the Ajar Productions subfolder.

Illustrator: Select Send Swatches to Flash from the File > Scripts menu.

Bonus Tip: Transferring Gradients

You can get a gradient from Illustrator to Flash by applying the gradient to a rectangle, copying the rectangle and pasting into Flash (CS3 or later). A dialog box will appear in Flash, make sure “Paste using AI File Importer preferences” is selected and it will retain you vector artwork, including the gradient! To get the gradient from InDesign to Flash, create the rectangle with the gradient in InDesign, copy and paste it into Illustrator, then copy and paste it into Flash using the instructions in the previous sentence.

FYI

I’ve added a donate button to the bottom of the navigation on the right-hand side of the page. If you’d like to help us spend more time making stuff that we can share with you, you’re welcome to leave a tip. Paypal is not required to donate. Donations are not tax deductible.

The short answer: Instance Names.

For the detailed answer check out this video tutorial using Actionscript 3.

The Actionscript has to know “who” you’re wanting to talk to. Just as we know human beings by name, and talk about them and to them by name, Actionscript references objects by name. A teacher might tell “Timmy” to sit down. Accordingly, your script might tell “circle” to move 10 pixels to the left. If no symbol with the name, “circle” exists, nothing happens; just as no one sits down if there’s no “Timmy” in the classroom.

Referencing nested MovieClips works the same way, just add a dot inbetween:
var clipReference = grandparentClip.parentClip.childClip;

Remember that a symbol name is different than an instance name. You can have multiple instances of a symbol on stage, but each instance name has to be unique. Instance names are set in the Property Inspector, symbol names are set in the Library.

Keep this idea in mind when working with Actionscript and it will make your life a whole lot easier.

A little while back I was looking for a way to quickly create icons to differentiate my project folders and speed-up my workflow a bit. I found exactly what I was looking for in Pic2Icon. It’s a droplet application for Mac OSX that turns an image’s content into its icon. It works with transparency and even layered Photoshop files (CS3 included). Once the icon has been applied to the image file, you get run a get info (cmd + i) on the image and the file you’d like to apply the icon to. Click on the image’s icon in the upper left of the get info window and copy it (cmd + c), then click on the target file’s get info icon and paste (cmd + v). Voilà!

I’m a big believer in the open-source movement and many times I’ve been able to find an open source solution that does the trick as well or better than a packaged piece of software can. So I started searching under the assumption that I would eventually settle on an open-source solution. In the case of Actionscript documentation, I found my ideal solution in VisDoc. It was one of the few solutions that had a Graphical User Interface rather than using a command line. It produces a beautiful set of documentation files. It works for both AS2 and AS3 (and Java). The one downside is that it’s Mac only. It’s not open-source, but with a sticker price of $40, it’s well worth the time saved. If you’re still looking for open-source or you need an app for your Windows machine, OSFlash has a comprehensive list of open-source documentations tools for Actionscript.