Don’t panic. Your application is not too big for Flex to handle. True, the 32K limit is really a Flash Player limitation to the size of certain structures, such as if blocks and for loops. But you don’t really care about that right now because you don’t have any direct control over those things. Here is some information that will help you get back to coding.
There are two main reasons why you might encounter the 32K issue. The primary cause—and the one to address first—is the architecture of your application code. The 32K error message asks you to “refactor” your code. Refactoring is essentially the process of modifying the structure of your source code while keeping the same functionality. In the Flex world, this means moving some parts of the code out of a main file and into separate components.
One way to do this is to use custom MXML components. So instead of, say, having several hundred lines of MXML in a child container of a ViewStack, you put that MXML code into its own component file and have just a single line in the ViewStack reference it. If you do that for all the ViewStack children, 1000 lines of code can easily become 30. Decreasing the total number of visually rendered MXML tags in a single file will help avoid the 32K limit. Another type of refactoring is to move ActionScript code into its own class.
Important note! Just putting the ActionScript code into a file and then using the #include directive or the mx:Script source=”myscript.as” method to include the code will not help with the 32K problem. You must create a true ActionScript class that contains the functionality. At 2000 lines of mixed MXML and ActionScript code, you are in danger of the 32K error. We have not found an upper limit whatsoever to code length in a class.
The second cause of the 32K error is not your fault. During compiling, Flex generates ActionScript code out of your MXML source. It then compiles that into the Flash SWF file. During that process it decides how to break up your source code and generate the ActionScript class code. In Flex 1.5 it doesn’t always make the right decision, and so the result is the 32K error.
If you are confident that your application is already efficiently “refactored,” and you suspect that you might be at one of these boundary conditions, first try compiling the app with ?debug=”true” in the URL. If the app compiles, then you are surely at a boundary condition. What happens is that debugging adds code to your source during generate/compile. This additional code causes Flex to change the structure of the ActionScript classes so that the application does not reach the 32K limit. Hmm, more code? Yeah. Try just adding 50 or so lines of code, even if it is bogus code. Usually, this will get you working. When you add more real code, remove the bogus code because you won’t want that in your production code!
We have found a third cause of the 32K limit error: There are some syntax errors that get by the compiler, yet cause the 32K limit error. At this time there is no example of the kind of syntax that can cause this problem, but you should be aware that it is possible.
A final hint: After hitting a 32K error and trying one of the previously described solutions, and if the error still occurs, delete the temporarily generated ActionScript code. It is located in ..\MyAppServer\flex(flexroot or contextroot)\WEB-INF\flex\generated\*. You can delete all the folders safely (make sure to restart your Flex server).
This can be an aggravating and somewhat scary problem, and it always seems to happen just before an important demonstration. Just use good, modular design and remember the bogus code trick. Adobe has stated that it is committed to improving this situation in the next release.
iDeveloper 