Documentation

Once a FLA file is compiled into SWF, most of the information about its internal structure and objects order is lost. As the result, SWF file size is greatly decreased which is a big advantage for the web usage. 

On the other hand, restoring original FLA file from SWF could be a problem. Situation may be worsened by many third-party Flash editing products that do not follow Adobe Flash specifications and introduce their own standards. 

We are working to reduce the number of conversion errors to the minimum; however, it is not always possible. We hope you understand that and will help and cooperate with us. You are very welcome to send erroneously converted files to our Support Team for investigation.

Below is the list of situations that are likely to lead to conversion problems:
 

• SWF file is compressed, optimized or obfuscated by third-party applications.
• Files, compressed with algorithms other than ZLib compression, may lead to erroneous conversion.
• SWF file may contain font, which is not installed in your system. In this case Flash will ask for a replacement when you open a converted FLA.
• FLA format allows placing as many objects on one layer as you want. However, SWF has a limitation of one object only. So objects will be placed into separate layers when converting SWF into FLA.

• Some Shape objects that have non-standard fills could be parsed incorrectly. The non-standard fill is the one that is present within a non-closed area that has gaps along its contour. Most likely it was created by a third-party application.
• Usually Morph shapes have beginning and ending states. When placing a morph shape on a frame, its intermediate state is used. It means that morph shape can be rewound/forwarded into any of its states in SWF. However, this is not possible within FLA format. They are placed on the timeline and always run from their beginning state to the ending one.
• When you compile your FLA file into SWF the first time, the hierarchy of the layers gets deformed. This peculiarity is important only for Morphs. When a morph is placed on a frame its state is remarked and written. It leads to the problem when a series of morphs can be "split" into several layers. Such frames cannot be correctly converted into FLA at this stage.
• Action buttons in FLA file are set when you place them on frames. In SWF files actions are stored in buttons themselves, that's why each button will be represented as a separate instance in FLA, even if they differ in ActionScript only.
• When the original FLA file is published into SWF format, all the original scenes are joined into one scene. Almost no information is transferred to the output SWF file about the original scenes. This information is almost impossible to retrieve. That is the reason why the output FLA file, decompiled from the SWF file, has only one scene. This fact won't influence the SWF file functionality after it is published from FLA.

• Texts objects contain symbols of a national (localized) alphabet. Learn how to solve problems with text conversion.
• When decompiling Motion Tween, you need to experiment with "Motion tween" settings.
• Code (in AS 3.0), written into timeline and movie clips, is placed into separate AS classes by Adobe Flash when published into SWF. In most cases it doesn't cause any problems. But sometimes the original file developer may give such sprite a name (in Linkage settings, Class field) which will be treated incorrectly by AS (e.g., a name starting from a digit or a name equal to AS keyword). Adobe Flash doesn't check the name, so there will be no problems during compilation. But during republishing after conversion, AS compiler checks the name and may give error message.
  Such files need to be corrected manually: one should move the code from functions like "public function frame1()" to the corresponding frame on movie clip timeline, and then delete these AS files.