There are several ways. The "theoretical" way is to rewrite your code. Populating ComboBoxes on hidden tabs is not a recommended practice. That is effectively having code in the app "pushing data down" into the controls. Instead, in any pattern that has MV in it, the recommended practice is that the components pull what they need from a model. If you do that rewrite, you may find that each Tab loads sufficiently fast when clicked on "on-demand". Maybe a busy cursor spins for a few seconds. Web pages often take a few seconds to load. But that may be a better experience than waiting 30 seconds for the first screen to show up.
Related, any tab that takes a few seconds to load may have its own "push data down" code in it and is initializing controls that may be in a sub-tab or has even sucked in a module or two. Profile each slow Tab and see what is going on. The "hacky" way is to use Pseudo-Threads. There are fancy Pseudo-Thread patterns, but the cheapest one is just a chain of CallLater functions. Maybe each one initializes a Tab then callLater's the function to initialize the next Tab. Still to slow? Then initialize half a Tab and callLater to initialize the other half. Other ideas involve re-designing the UI to use more deferred-instantiation components. FWIW, many years ago I saw a great presentation on UI design by a magician. He talked about understanding human behavior to create illusions. There is also a classic book called "Computers As Theatre" by Brenda Laurel. In live theatre (as opposed to movies), there is the reality of having to find ways to get people and props on and off the stage without distracting the audience. These ideas can apply to problems like this one. If you know that folks will dwell on the first screen for N seconds before they can even decide what to click on, then you've got N seconds to initialize stuff in a pseudo-thread. If you have Tabs that scroll, you can just initialize the first screenful of UI widgets, then you probably have another second or two to initialize stuff off-screen. Busy cursors, UI effects, progressive reveals are all techniques that can be used to create the illusion that the UI is ready to go, when in reality, your stage crew is hustling in the dark behind the sofa. HTH, -Alex On 2/10/19, 4:57 AM, "Paul Stearns" <[email protected]> wrote: OK, I downloaded Scout & ScoutEnabler. I learned enough to be able to run it and I found the problem area. The swf in question has 10 tabs with more than 300 objects spread among the tabs. The TabNavigator has creationPolicy="all" set so that once the swf is loaded the "as" code can start populating various comboBoxes and other components on the hidden tabs. My working hypothesis is flash get's "hung" building all those components at once. If this is the case, how can I get rid of creationPolicy="all" and once the screen becomes visible, force the creation of all the hidden tabs before I try to populate them? While this may take a little longer, it would provide a better user interface. ---------------------------------------- From: "Paul Stearns" <[email protected]> Sent: 2/10/19 6:55 AM To: "[email protected]" <[email protected]> Subject: Profiling I have a routine that "disappears" for a few seconds. I would like to turn profiling on just before this begins and off when it comes back. Is this possible? Since the app does many things, I want to isolate just this section where as far as I can tell it is not executing any code from my application. I am currently using FlexBuilder 3, but will use whatever is available as long as the learning curve isn't too steep and it works with my 3.6 code.
