5 Replies Latest reply on Apr 6, 2008 12:42 PM by flexsea

    Concurrent actions in Flex question

    crzymnmchl Level 1
      Thanks for the link to LightGauge (nice component!). Could someone point me towards docs/links where I can learn how I might feed a component with ongoing info e.g.

      channel.leftPeak;
      channel.rightPeak;

      while still allowing the user to type in information etc and the app carry on as usual? Flex is not multithreaded, right, so one cannot just spawn a thread that takes care of pushing the data to the sound visualizer, and carry on "as normal". So when it comes to multiple GUI components doing things, is it all about event generation/listening/processing where many events are processed in quick succession and not concurrently, but the speed allows it to behave as though concurrent? ( I know what I mean :-). So channel emits events that can be trapped and sent to a GUI meter and this is so fast that the rest of the GUI can still listen and respond. Timers can be used of course, but I am presuming we have progressed from that necessity :-). Thanks in advance,

      Mic.
        • 1. Re: Concurrent actions in Flex question
          crzymnmchl Level 1
          Reading LiveDocs. SoundMixer about

          addEventListener(Event.ENTER_FRAME, onEnterFrame);

          which I know from Flash ... could somebody explain whether the enter_frame event is somehow available and generated by Flex, or is Adobe recommending that this kind of "animation" is done within a Flash movie and then embedded into Flex? As always TIA,

          Mic.
          • 2. Re: Concurrent actions in Flex question
            crzymnmchl Level 1
            I'm not really answering myself :-) ... It looks like if one creates a project within Flex as an Actionscript project, one can have

            package {

            import flash.display.Sprite;
            import flash.events.Event;

            public class EncapsulationExample extends Sprite {

            public function EncapsulationExample() {
            addEventListener(Event.ENTER_FRAME, onEnterFrame);
            }

            private function onEnterFrame(evtObj:Event):void {
            trace("Hello from onEnterFrame");
            }

            }

            }

            i.e the use of EnterFrame for animation e.g. a stereo vu meter ....
            but I think this would preclude using the <mx:> tag where all the lovely Flex Gui sits.
            • 3. Re: Concurrent actions in Flex question
              slaingod Level 1
              Yes, you can use EnterFrame like that (though it is discouraged). Sometimes it is the only way to do certain things tho. Typically you would simply set a flash.utils.Timer to tick every 50ms or 100ms (0.05s or 0.1s) or similar and do you update then.

              I believe the resolution is based on the frameRate of the application, so a 24fps app will have a resolution of at most 41ms. You can always say set the fps to 60 tho, but any included swf's would also need to be created at that speed.

              If you want more accurate timing, you would need to go even lower and use the getTimer method.
              • 4. Re: Concurrent actions in Flex question
                crzymnmchl Level 1
                Thanks ... I talked to Alex who wrote LightGauge and he is using timers. I wonder if Timer is interrupted by e.g. keyboard activity e.g. if there is intense Timer activity and the user wants to type into fields, whether the keyboard events take priority and interrupt the Timer events momentarily so that the user can type. This would be user-friendly but produce inconsistent TImer events - but can't have best of both worlds obviously! I shall create bar leds for a 128 track mixer and then try to type :-)
                • 5. Concurrent actions in Flex question
                  flexsea
                  Instead of creating an enourmous amount of timers, you might probably wish to create a Scheduler class, which you would provide with tasks to perform. The Scheduler could then decide, how much jobs it should execute during a time slice. The Scheduler itself would be kicked-off in a regular fashion using a single timer. This way, you might probably control the overall load.

                  Additionally, callLater() might be helpful, since it postpones activity to the next event loop. Well, probably everyone knows...