Batch Import Images into Flash Symbols

When I find a workflow I like, I sometimes assume that everyone has already discovered that workflow, and I'm late to the party. One of the nice things about participating in user forums is that sometimes that helps me realize that a favorite workflow isn't known to everyone. This is great, because then I have something to blog about!

Today, I want to talk about what is probably one of my all-time best productivity tricks in Flash. In a few minutes, I can:

1. Import a series of pngs, jpgs, or whatever into my Flash movie
2. Choose for each image to be wrapped in a symbol or not
3. Have the symbols and images nicely organized into folders in the library, without any extra effort!

Here's how I do it, starting with a folder of images:

Step 1: Browse the folder in Bridge

First, I right-click on the folder of images and select "Browse in Adobe Bridge"

Once it opens, I select the images I want to use. For this post, I just selected everything in the directory, but Bridge has excellent features for finding just the images I want (that could be a blog post in itself). You can drag them around in Bridge to change the order, if you need to.

Step 2: Load the files into PhotoShop Layers

In the Bridge "Tools" menu, I select PhotoShop>Load Files into PhotoShop Layers.



This launches PhotoShop and does all the work to put the files into PhotoShop layers, in the order they were in in Bridge. Once that has finished running, save the result as a .psd.

Step 3: Create a Symbol in Flash to Import into

Whenever I have to create a new Symbol in Flash, I like to start with a rectangle that's the size I want the MovieClip to wind up, so the registration and transformation points fall in predictable places. So, I create a rectangle the size of my images and convert it to a Symbol (F8).

Step 4: Import the PSD

I usually use the keyboard shortcut to import to stage (Ctrl-R). The import dialogue gives me lots of options. For example, I can select all the images and choose to convert them to MovieClips.

I'll usually convert the images to MovieClips if I want to do timeline animation with them or if I want to apply a base Class to the MovieClip. I can also choose to import each to a different layer or to a different keyframe. Both options are useful, depending on the end result I need.

Once the psd has imported, the timeline looks like this.

Note that the frames will be the reverse order of the order they were in in Bridge. I usually select the frames and reverse the frames (there's a right-click menu for it, but I've set up a keyboard shortcut).

Step 5: Edit the Library Symbols

The MovieClips and Images are nicely organized, but usually there is more I want to do to them.

If I'm applying a Base Class, I might want to rename all the Symbols, for instance, to change ".png" to "_png." I like the Search and Replace extension for this.

Flash also allows you to edit more than one library symbol at a time, by selecting several symbols and clicking the Properties button (sorry, if there is a shortcut for this, I haven't found it).

From this dialogue, you could change all the MovieClips to Graphics, for example, or you could set a Base Class on all the MovieClips at once. Tip: if you set a Base Class, Export for ActionsScript will become checked and the drop-down will have "Yes" selected, and you don't have to touch it.

And that's it, my quick and easy workflow for importing a series of images to Flash.



Reusing a Flash Builder Workspace

I use Flash Builder and Flash Pro together, and over time I have learned to just bow to how Flash Builder wants me to do things. What this means is that each "family" of Flash files has to have its own Workspace, because Flash Builder expects the Flash file to be in a subdirectory of the workspace in a directory that's the named the same thing as the Flash file. If that's not where it is, you either have to remember to tell Flash Builder not to use its default or things go very wrong, very fast.

In a team environment, the process has to be as simple as possible, without a bunch of fiddly steps that people have to remember to do at exactly the right moment, so it's just easier to go with what Flash Builder wants us to do. However, this adds other fiddly steps that people need to do each time they start a new workspace, such as importing snippets and laying out all the panels just so.

So I thought I'd hit on a brilliant plan, which is just to check the workspace settings into version control that live in the .metadata folder. This way, everyone would get a workspace that's already set up when they export the "base" Flash project and they could just start working. And this does work for the intended purpose, but I found that workspace relative paths would break (paths that refer to the ${DOCUMENTS} variable). These would unaccountably point to the original base project directory.

On Windows, for whatever reason a file contents search didn't turn up the offending string. I suspect this has to do with the weird way the .metadata folder starts folder and file names with "." So I was off to Google to try to find out how other people transfer their settings. I found one post that suggested you just copy the .metadata/plugins/org.eclipse.core.runtime/.settings directory. The result I had from that was that the site relative root now pointed to the project I'd copied the directory from. At least now I had it narrowed down to a large handful of files that I could then open and look at individually.

To save you the bother, I'll tell you that the file that contains the location of the workspace for workspace-relative links in the above directory is called org.eclipse.core.resources.prefs, and that file contains the pathVariable.DOCUMENTS string that tells Flash Builder/Eclipse where the workspace thinks it is. I haven't had a chance to play with it to see if simply not putting that file in version control makes things better or borks them, but even if everyone has to manually update that variable when setting up a project it's much better than having to set up every workspace from scratch when we start a new project.

FlashTips #5: Copy Variables in Flash Builder

Have you ever wanted to copy all the values of the member variables of a Class instance you were debugging in Flash Builder? If the data types of those variables are simple, you can do this pretty easily by right-clicking on the variable name in the variables panel and selecting "Copy variables." This will copy the name of each member property and its value to the clipboard. Values that are Strings, Numbers and Boolean work, but XML does not--it just copies "XML" as the value--and I suspect that other complex types will not work well either.

As an example of how to use this, today I wanted to copy the contents of the loaderInfo.parameters (a.k.a. FlashVars) so that I could remind myself of what values are incoming. I right-clicked on the parameters object, copied the variables, and pasted into Notepad for future reference.

FlashTips #4 Turn off AutoSave on reference projects

When a Flash Pro project is not set up to save automatically, it will prompt you to enable autosave when it has unsaved changes. I usually say yes, because I don't like to lose work. However, Flash considers a file to be "changed" even if you've just popped open a MovieClip to see where that button is so you can duplicate its position elsewhere.

This can make it inconvenient to have a file open to use it for reference as you work in another file, especially if you use version control. Fortunately, I discovered a way to get around this behavior recently.

Simply click the "wrench" icon in the file Properties panel. This will open a dialogue with a check box you can uncheck the Autosave option while you have the file open, using it for reference. If you don't save the file when you close it, your explorations in the file won't be saved and cause your file to show as edited in version control. Since you didn't save the Autosave change either, next time you open it to edit it, it will Autosave as usual.

When Good (Flash Builder/Flash Pro) Projects go bad

I love Flash Builder—especially the refactoring help—so it broke my heart when I found that many of my favorite features, such as renaming variables and classes on the fly, didn't work. I was also getting all sorts of weird other problems, such as getting two copies of warning and error messages. I also couldn't edit files when I spotted problems in debug mode, because I'd get a weird error message that the file I was trying to edit was a "generated file," whatever that means.

Finally I figured out that all these issues were symptomatic of the same issue—accepting Flash Builder's defaults when I created a new Flash Pro project. Let's take a step back and look at what the history of my project was. First, the team I am on primarily develops in AS2, and we have a lot of relative path #includes and a source path that point to the same place on everyone's hard drive. To support this, everyone has the same directory structure.

At the moment, I'm reworking the existing code into AS3, but the last thing I want to do is introduce an unfamiliar directory structure. So I used the normal team directory structure and pointed my Flash Builder project at the usual location. What I somehow failed to realize was that Flash Builder has a default place it wants projects to be, so it created a directory in that spot with the same name as my xfl file. This is where all my actionscript files were being "generated" to for use in Debug. Not only did this cause the "generated files" method, but somehow it borked most of the refactoring support in the project.

So how did I fix it? First, I made sure to put all my code into version control, just in case something went wrong.

Next, I deleted the project, making sure to deselect "Do not delete contents." This gets rid of the shadow project and its files. Next, I added it again (File>New>Flash Professional Project). When I selected my target file, I unselected "Use Default location." Since this is an XFL project, when I clicked the "Browse" button next to "Project Location," I navigated to the directory that contains the directory with my XFL file in it. If you were doing this with an fla project, you'd probably want to navigate to the directory with the fla in it.

That fixed the problems with the day-to-day operation of the project, but it created a new one. My project uses xml files to drive a lot of the content, and these were no longer loading properly when I launched the project from Flash Builder, though they worked fine when launched from Flash Pro. The reason for this issue is that Flash Builder created a bin-debug folder next to my xfl folder, but we traditionally expect that Flash Pro will make the swf next to the xfl (so that is where the XML files are stored). The final step is to go into the Project Properties in the Run-Debug Settings and edit the path to point to the root of the project.

FlashTip #3: What color is that thing in Photoshop

If you've ever searched on "Photoshop for Developers," you've probably noticed that most results are either really shallow or should more aptly be titled Photoshop for people who can't read the help and figure it out. So, I thought I'd post every once in a while when I find something that helps me with my real workflow as a working developer. It will probably still be shallow, but at least I know it fills a real need.

Today, I want to talk about what to do when you get a file where you need to find out what color something on a layer is, but it is so covered up in effects that the eyedropper tool won't work. If you're lucky, the designer has included a palette, but somehow that brand of luck and I seldom meet.

Recently, I discovered this simple tip to find out what color that object is (assuming it's a solid color underneath). All you need to do is click the dropdown to the right of the "fx" in the layers panel, then click the eye icon to turn off the effects.