When you double-click an MXP (or ZXP) file, your operating system open your default version of Extension Manager. This may not be the version that you want, however. Suppose you have Flash Pro CS4 and Flash Pro CS5 installed. Your system will (probably) automatically launch Extension Manager CS5 when you attempt to install a new extension. This is okay if you want to install the extension in Flash CS5, but it will not be available in Flash CS4.

There are other issues that crop up when you have versions installed in multiple languages (and in some cases, if your language is not English). Luckily, there’s a simple way ensure that you’re using the correct version of Extension Manager.

1. Launch the version of Flash Pro (or Dreamweaver, or Fireworks) in which you’d like to install the extension.
2. Go to Help > Manage Extensions… and it will launch the matching installation of Extension Manager.

What differentiates a feature from a bandage? Here are some characteristics of a feature:

1. Can be turned on or off, usually with a single variable.
2. Does not interfere with existing functionality (i.e., when the feature is turned off, the application should function just as it did before adding the feature).
3. Easy to read code (i.e., dependent code can simply check to see if the feature is on, rather than testing several ambiguous conditions).

Bandages have almost the exact opposite characteristics: can’t be easily reversed, interfere with existing functionality, and usually very difficult to read. Features also have the added advantage of being useful later. Even if you do not using the exact same code base, when your code is written as features, rather than cobbled together to serve a micro-specific purpose, it’s much easier to copy code from one project to another.

There are several techniques that differentiate feature-building. Consider the simple example that follows into in order to examine some of those techniques. Suppose your application includes the following 3 functions: navigateTo, nextPage, and prevPage. Your application plays start-to-finish automatically triggering the 3 aforementioned functions, but your client has indicated that they would like the application to pause when it reaches the end of a section. Additionally, the client wants the backward (e.g. when the user presses the back button) navigation to stop when the beginning of a section is reached.

Bandage Approach

First, have a look at a bandage approach. Since you know the page number that corresponds with each section, you could quickly hard-code these values into the respective functions.

function navigateTo(page) {
//no change in functionality
}

function nextPage(){
if(currentPage == 11 || currentPage == 18 || currentPage == 24 || currentPage == 30) pause();
else navigateTo(currentPage+1);
}

function prevPage(){
if(currentPage != 12 || currentPage != 19 || currentPage != 25 || currentPage != 31) navigateTo(currentPage-1);
else /*do nothing*/;
}

While this solution will work from the client’s point of view, it will get messy for you if a page needs to be added anywhere (lengthening a section and changing all of the relevant page numbers) or client decides that this feature is not needed after all. Even worse, what if the client loves it and wants more new functionality…now you’ll have to add bandages on top of bandages.

Feature Approach

One way to improve upon the bandage approach is to move the logic to a central location. This can be done in the example above by moving logic from the nextPage and prevPage functions to the single navigateTo function.

function navigateTo(page) {
var sectionStart = (currentPage == 11 || currentPage == 18 || currentPage == 24 || currentPage == 30);
var sectionEnd = (currentPage == 12 || currentPage == 19 || currentPage == 25 || currentPage == 31);
if(sectionStart) {
disableBackNav();
} else if (sectionEnd) {
pause();
} else {
//run normally
}
}

function nextPage(){
navigateTo(currentPage+1);
}

function prevPage(){
navigateTo(currentPage-1);
}

The purpose of this code is already slightly clearer than the bandage approach. The logic has moved out of multiple functions and into a single function that is called by the other two. Two variables are then created, sectionStart and sectionEnd, to test the location of the current page. The conditions that determine these values are adjusted based on the currentPage location, which will have already been altered by nextPage or prevPage (unlike the bandage example above). Additionally, the navigation will function properly even if it’s not triggered by the nextPage or prevPage functions, because all navigation is routed through navigateTo.

While jumping in with a bandage approach can seem quicker in the short run, you can see that difference in the amount of code required between these two examples is negligible. Additional improvements can be made to the code by moving the section start and end numbers out of the navigateTo function and to a location that is easy to find and edit (like the top of the code). Ideally, these numbers would not have to be present at all. If the data that contains page information, often stored in XML, clearly groups sections, section starts and ends can be determined dynamically, rather than hard-coding actual numbers that are likely to change.

A sample bit of XML might look something like this:
<root>
<section name='Introduction'>
<page name='Welcome' id='010101' />
<page name='Course Navigation' id='010102' />
<page name='Initial Questions' id='010103' />
</section>
<section name='Tools'>
<page name='Toolbar' id='010201' />
<page name='Calculator' id='010202' />
<page name='Navigation' id='01020' />
<page name='Selection' id='010204' />
</section>
<section name='Course Review'>
<page name='Review Screen' id='010301' />
<page name='Close Course' id='010302' />
<page name='Submit Results' id='010303' />
</section>
</root>

As sections are added to the application structure, the application dynamically reads the section breaks from the clearly-defined XML data.

Further refinement would involve creation of variables like pauseAtSectionEnd and lockBackNavAtSectionStart that are set at the top of the code. Thus, each feature can easily be enabled or disabled without diving down into functions that contain other purposes. This has the additional benefit of reducing the chances that you might break something that was already working in the code, which can happen from deleting even 1 character accidentally.

In short, bandaging assumes on some level that you’ll never have to look at the code again…so what does it matter how organized it is, right? In my experience, this is almost never the case, bandaging will always come back to haunt the developer. Building features rather than applying bandages has made my life a lot easier as developer. Furthermore, it’s made me popular among my colleagues, because this type of code construction has facilitated easy updates and fixes when they’ve needed them in a hurry. I hope this post helps you to think about your projects in a new and helpful way.

var nm:NativeMenu = NativeApplication.nativeApplication.menu;
var nm0:NativeMenuItem = nm.getItemByName('File');
var mi:NativeMenuItem = new NativeMenuItem("Export...");
mi.addEventListener(Event.SELECT, exportSelected);
nm0.submenu.addItem(mi);

Unfortunately, the menu item resolves to null in the above code and subsequently generates an error. Instead, I’m using the following code (that works):

var nm:NativeMenu = NativeApplication.nativeApplication.menu;
var nm0:NativeMenuItem = getMenuItemByLabel(nm, 'File');
var mi:NativeMenuItem = new NativeMenuItem("Export...");
mi.addEventListener(Event.SELECT, exportSelected);
nm0.submenu.addItem(mi);

The getMenuItemByLabel function is as follows:

function getMenuItemByLabel(menu:NativeMenu, labelName:String):NativeMenuItem {
var count:uint = menu.items.length;
for(var i:uint=0; i < count; i++){
var item:NativeMenuItem = menu.getItemAt(i);
if(item.label === labelName) return item;
}
return null;
}

That way I can get the menu by name and rest assured that I’ve added to the File menu (or any other existing menu) without having to guess its index.

5 Flash Animation tips in 5 days on the Peachpit blogs:

• Flash Animation Five Tips in Five Days: Tip 1 – Easing
• Flash Animation Five Tips in Five Days: Tip 2 – Distribute to Layers
• Flash Animation Five Tips in Five Days: Tip 3 – Bitmap Masking
• Flash Animation Five Tips in Five Days: Tip 4 – SWF History
• Flash Animation Five Tips in Five Days: Tip 5 – Targeting Nested Symbols with ActionScript

Also on the Peachpit site, there’s an excerpt on Character Animation from our recent book with Chris Georgenes.

I also have a new video tutorial over at ActiveTuts+ on Creating Advanced Motion Presets in Flash with JSFL.

In addition to the recent advice page I added on Learning Flash, I’m working on a page about becoming a graphic designer/Flash animator/digital artist. It includes some of my background and lessons learned. That article is pretty much on hold as we work toward the SmartMouth release (hopefully just another week), and I will pick it up after that.

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.

Update (1/12/10): Flash CS5 now has direct JSFL access to the calls documented in this post. Check out this video tutorial that I produced on ActiveTuts for more info.

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.