8 Replies Latest reply on Aug 24, 2009 5:43 AM by Jason Villmer


    Jason Villmer

      I've been working between Flex Builder 3 and Flash Builder 4 for some time now. I'm quite excited about where Flash Builder is headed despite the rough start migrating my styled (css) project from Flex 3 to FB4. One of the first issues I had was getting the application to retain the aesthetic qualities I had spent so much time on in Flex 3. It took a while and, thanks to the great support here, I managed to get it right. Which brings me to the next thing.


      To resolve my style issues I had to first change namespace declarations in the .css file. Then I had to add a line in the Compiler Arguments. (Properties > Flex Compiler > Additional compiler arguments:)


      That line was this: -theme=${flexlib}/themes/Halo/halo.swc

      Now, to my great satisfaction, it looks and functions exactly the same in both FB3 and FB4. Why not add a drop down list of all the Additional compiler argument available? (with the user having to add the specifics). Without someone from this forum telling me to add that line I never would have figured out that to retain my style I had to force the halo theme in that way.


      Just a thought.




      Another thing I noticed is that the 4.0.0 SDK compiles all necessary elements into the single swf file. (as expected) However, SDKs beyond 4.0.0 would compile the swf WITHOUT certain things. At first I was astounded to see my swf drop from 800k to 200k! Then I realized that the swf would load the other things from the network at runtime on the web (as I noticed my loader bar would be re-loading multiple times to indicated several things being obtained prior to completion). Although this is somewhat interesting, I'm not sure I care for it personally. I'm curious if this method will continue to be used for all SDKs beyond the original 4.0.0? I like having everything I need in a single swf and seeing that loader bar update only once, regardless of how many things it must load simultaneously.



        • 1. Re: Thought
          TeotiGraphix Level 3

          Hi Jason,


          In regaurds to your question about loading framework classes over the network and wanting one swf, I think your answer is in this;


              <!-- static-link-runtime-shared-libraries: statically link the libraries specified by the -runtime-shared-libraries-path option.-->


          The above line is found in the flex-config.xml and is turned OFF by default right now.


          Navigate to your sdk directory, find the flex-config.xml file and set the value to true. This will create all needed classes in one swf.






          • 2. Re: Thoughts
            Jason Villmer Level 1



            Thanks for the fast response. Do you know if this will be returned to 

            'true' by default in the future? Any particular reason the SDK's 

            beyond 4.0.0 are implemented in this way? I suppose I can see some 


            • 3. Re: Thoughts
              TeotiGraphix Level 3



              I wish I knew, I had a pain in the... when they first switched. I couldn't understand why the debugger was trying to load the text layout framework.


              Seems like this might be for the beta. I know Adobe has a motto, give functionality, turn it off and let the developer enable it. If they left this compiler arg on, it would seem like they are going against that principle.




              • 4. Re: Thoughts
                Jason Villmer Level 1



                I agree that providing developers with the option to choose which 

                functionality they wish is a good approach. However, when a developer 

                doesn't know that they do, in fact, have choices or know how to change 

                choices that have been made for them - then it becomes a problem. I 

                didn't know anything about the static-link-runtime-shared-libraries. 

                One day it worked one way, the other.. another. So, I agree in choices 

                but we should know how to make them if we don't like what's been 

                chosen for us.

                • 5. Re: Thoughts
                  Jason San Jose Adobe Employee

                  Hi Jason,


                  There's an option in Flash Builder to set the framework linkage. Go to your project properties, Flex Builder Path > Library Path tab, "Framework linkage" and select "Merged into code". This will include all your dependencies in your SWF instead of loading RSLs at runtime.


                  Jason San Jose

                  Quality Engineer, Flash Builder

                  • 6. Re: Thoughts
                    Jason Villmer Level 1



                    Thank you Jason. I had, in fact, never actually noticed the 'Framework 

                    linkage' menu option before!



                    Jason Villmer

                    • 7. Re: Thoughts
                      Jens Wegar Level 1

                      I'm not sure if this will stay as the default option in the future, but I think the reason for the RSL:s not to be included in the compiled swf by default is that Adobe wants users to start caching the framework libraries in the Flash player. The rationale behind this is that the first application to load a particular RSL will have the overhead of having to download the file. The next application that needs those same RSL:s will not have to download them, since they're already in the cache of the Flash player, and thus the download size of the new application will be smaller and startup time will be faster. Now for extremely domain specialized RSL:s (like e.g. your own custom library) it will probably not make much of a difference whether you include it in one swf or load it as a RSL. But for framework RSL:s that come with the SDK, it's probably wise to link to them instead of including them in your compiled swf. Reason being that it's very likely that there will be a whole bunch of applications out there using the same version of the framework, and thus it's very likely that a user will already have those RSL:s in their cache = faster startup time for your application.

                      • 8. Re: Thoughts
                        Jason Villmer Level 1



                        Thank you for clarifying this for me. I suspected it was something 

                        along those lines. I can certainly see the benefits.