3 Replies Latest reply on Oct 1, 2008 11:38 PM by Dmitri P.

    Show progress bar while module loads

    JasonMH Level 1
      I have a TabView where each tab is a module. One of the modules has a lot of child components and when I click to activate that tab - it takes 2-3 seconds to load. During this time OSX shows the beach ball.

      Is it possible for me to show a loading progress bar instead? Should I be pre-loading all the modules when the application loads, or at some other point? If so, how do I do this?

      Any suggestions would be appreciated.
        • 1. Re: Show progress bar while module loads
          JasonMH Level 1
          bump. please, does anybody have any clues?
          • 2. Re: Show progress bar while module loads
            JasonMH Level 1
            I don't know why it seems I can never get any help here? I try to post solutions for people whenever I can. Are my questions really stupid and/or really unusual? Can anyone suggest better help forum or community that is more active?

            If anybody cares, setting the creationPolicy to ContainerCreationPolicy.NONE and then using createComponentsFromDescriptors() when needed has been a solution for my app. I was able to radically improve the perceived speed.

            It causes some other weird side effects, but I'm working through those.
            • 3. Re: Show progress bar while module loads
              Dmitri P.
              Hey Jason,

              I'm not sure who moderates, but I can send you in the right direction.

              Short answer: Look around for Asynchronous Flex demos

              Long answer:
              The interfaces locks up (beach ball/hour glass) because the main application 'thread' is busy with the task you asked of it. This can, in many different languages, cause a freeze. Javascript, Native Mac or Windows applications, apparently Flex too.

              Running one task at a time is considered a synchronous (serial) request. What you need to do is make an asynchronous (parallel) request. In the web world, that's the 'A' in Ajax. By making asynchronous requests, you free up the main 'thread', while a separate worker thread is off completing the task. This keeps your interface responsive.

              I think that leads to event listeners.. Send off a background request, but listen for it to complete. Link the listener to a second piece of code upon successful completion.

              I wish I could get into more detail, but I'm not a Flex guy.. hoped that at least helped gel the idea.