Fun with Compiling – When Flash Goes Quiet

Today I finally figured out an issue I’ve been having for the past day and a half. I was working on project that required me to parse through an xml file based on a few parameters, which is a small part of a much larger project.

One of the parameters determined which node of the xml file I needed to start parsing from, so I quickly threw together a line of code I’ve used elsewhere countless times with no issues.

In the past, I’d only ever used the shorthand if else statement to assign simple data types like booleans, strings, numbers, etc.  So it never really occurred to me that this wouldn’t work the same as any of the other times I’d used it.  Boy, was I wrong.

I wrote that line of code not really thinking anything of it, it was a small part of a much larger class that I wrote in it’s entirety before beginning my testing.  The swf compiled with seemingly no errors.  When I went to test this new functionality, I was met with a runtime error stating a function I was trying to call did not exists.  This function was from a completely separate class that was defined in the document class of the swf I was loading and (before then, successfully) calling methods on.  Not only that, but trace statements placed in the constructor function of the document class would not run.  No methods from the document class were available.  It almost seemed like the document class wasn’t being linked, even though flash was telling me it was. I dismissed this idea when I found I couldn’t even get a trace statement to run from the timeline!

I was stuck.  After some tinkering I realized if I removed the document classes and all linked classes from the swf, it would run the trace statement in the timeline.  The next thing I did was link the document class back to the swf file.  The trace statement didn’t run.  My only option left at that point was to comment out every function in the document class, and systematically uncomment each function one at a time, compile, and see if the trace statement still ran.  If it didn’t, I would comment out each line in the offending function, and uncomment them one by one, saving, compiling and looking for the trace statement.  If it didn’t run again and the line was instantiating a new class, I would switch to that class and start the process all over again.  This went on seemingly forever…

Finally, after going through the entire document class and several linked library classes, I came upon the culprit:

var startNode:XMLList = (type == "all") ? _contestXML..modules : _contestXML..modules.(@moduleName == type);

Apparently, this line of code destroys the compiler, so much so that it can’t even report any errors whatsoever.  This code, however,  works flawlessly:

var startNode:XMLList;

if (_contestType == "all")
{
     startNode= _contestXML..module;
}
else
{
     startNode= _contestXML..module.(@moduleName == _contestType);
}

So what’s going on here?  Honestly I’m not sure.  I don’t know why the shorthand version of the above code causes compilation to fail silently.  As far as flash was concerned, the compilation was successful.  There were no errors or warnings.  Nothing saying the compilation had failed.  Only by loading the swf and attempting to call methods on it would I get an error, and even then that didn’t make sense because the methods were in the document class which flash was telling me was successfully linked to the .fla file.  If anyone knows why using this line of code causes compilation to fail silently, I would love to know.  For now at least, I know one more thing not to do…