SoThink SWF Decompiler (Thoughts, Bugs, Suggestions)

I recently had to use a SWF Decompiler to recover a lost FLA and code library. This is my first experience with a decompiler so I am not sure how SoThink compares to other companies. I chose SoThink because they seemed to have a solid reputation and active forum.

I was a little scared at first when I had trouble getting my registration key and noticed there were many similar posts in the forum, but their support reacted within the first 24hours as promised and I was good to go.

I was able to grab my FLA and then separate my code library without trouble. But when I went to try to compile I found out I was in for a ride... Compared to redoing the entire project, every issue I list below is minor and petty. However, it would be nice to have everything working right out of the box.

Issues with the FLA:
All of the MovieClips, Layers, etc were renamed to things like "Layer 2" or "Sprite 255". I realize most of this is unavoidable since the Flash IDE ditches any unnecessary info when it compiles. However, instead of naming it Sprite 255, it would be nice if it named it to the Class Name. If it was based off of "some.package.DropDownMenu" I don't think it would be hard to call it "DropDownMenu 1". Better yet, why not make a folder structure in the library mimicking the package? Create a folder called "some", another called "package", and then place the DropDownMenu movieclip there. I think its pretty standard for most developers to follow a similar file structure, and if not, it would at least be easier to understand than looking through a few hundred sprites. Just a thought... or wish for next version.

Another issue regarding the FLA is that the library assumes everything is based off of MovieClip and is exported on Frame 1. Its easy enough to write a jsfl script to change the export frame, but having to go through and reconfigure base classes was a pain in the ass. Not sure if the compiler ditched them or if SoThink just assumed they would be movieclips.

Issues with the Code:
The compiler keeps the name of any class variable (public, private, protected), but ditches all local variable names. So be prepared to see a bunch of code chalk full of "_loc_1" and "param1". It is annoying, but unavoidable due to the compiler. What is not unavoidable are the bugs created by SoThink's decompiler.

Original Code:

var margin:Number = 5;
this.leftMargin = this.rightMargin = margin;

Decompiled Code:

var _loc_1:Number;
this.leftMargin = 5;
this.rightMargin = _loc_1

Basically, instead of setting both Margins to 5, it sets the Left to 5 and the right to 0 since _loc_1 is never set. No compiler errors, just makes your project look like crap and can be fairly tough to uncover initially.


Another Example...

Original Code:

for(var i:int=0; i<this.total-1; i++){
// Something
}

Decompiled Code:

var _loc_1:int = 0;
while(_loc_1<this.total--;){
// Something
_loc_1++;
}

For some reason, when ever you try to change a variable by 1 in a conditional statement (if/while/for) it will change it to either -- or ++. This is not good since -- subtracts 1 from the total and then assigns it to the total. So each time this loop is called, this.total is decreased. Therefore if you had a list of 5 items then you would only get through 3.

------------
Granted, without this software I would be behind a couple months of work so I can't complain too much. However, it would be nice to have it not break the code and possibly clean up the FLA library so it is a bit more readable.