Tip for the day: If trace() is not working in Flash Builder debug mode, try quitting Flash Builder and all browsers and delete the mm.cfg file. For some reason this fixed the issue for me…
Today I was attempting to run a grep search on all the *.as files in the project code I am working with. The code in places is both old and new and has been edited in a variety of editors, from the Flash IDE, to TextMate, to Flash Builder, to who knows how else. The unfortunate result of this history is that many of the files have Mac style line endings (\r) instead of Unix style line endings (\n). When trying to run a grep search on these files, the search returns a bunch of jumbled code salad.
Since I was only really wanting to do the search for now, I ended up using:
tr '\r' '\n' <filename.txt | grep searchstring
This works by using the transform command to convert the mac line endings, and pipe out the result to a grep search that is now happy. For more permanent results, the line endings could be replaced entirely using:
perl -pi -e 's/\r/\n/g' textfile.txt
The “tr” command, however, was a great temporary work around for running the search on the files that I needed to run, since I didn’t want to end up having to recommit a bunch of files to SVN just to change the line-endings. The original jumbled search result I was getting was somewhat inexplicable until I started analyzing the reason why it worked for some files and not for others. Hope this helps someone out there.
Something I suppose I had never really tested thoroughly before having not had to deal too much with random application embeds in the wild is the issue with ExternalInterface.available not quite doing what you might expect. According to Adobe documentation, this property
Indicates whether this player is in a container that offers an external interface. If the external interface is available, this property is
true; otherwise, it isfalse.
This is usually fine, as long as your embed has allowScriptAccess defined to either “always” or “sameDomain” (when the embed lives on the same domain as the swf). In addition, when prescribing embed code for folks to use, one would normally provide the embed code with allowScriptAccess set to “always” if there was a need to use ExternalInterface. Unfortunately, the ExternalInterface.available property will return true in cases where the allowScriptAccess parameter is not set to allow access (such as on Facebook flash embeds, where it is always rewritten to “never”) or when an industrious embedder has removed all the seemingly extraneous parameters from the embed.
The solution for this scenario is to always use a try-catch statement to trap any errors that occur when trying to access the ExternalInterface, and deal with the error accordingly. This might look something like:
if (ExternalInterface.available) {
try {
ExternalInterface.addCallback(“moo”, onMoo);
} catch (error:SecurityError) {
trace(“Error: ” + error.toString());
}
} else {
trace(“ExternalInterface is not available for this container.”);
}
This is not super pretty, but this will ensure that the app doesn’t generate any unexpected behavior in the wild.
