FlashTips #5: Copy Variables in Flash Builder

english mobile

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

english mobile

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

english mobile

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.