1 Reply Latest reply on Oct 24, 2007 7:17 PM by Ansury

    Realtime apps in Flex

      I'm a Windows/MFC developer interested in Flex because of the platform independence, but the apps I am developing are for realtime machine control / monitoring / reporting and there would be a requirement to be able to hook up the GUI developed in Flex to communicate with native applications. Here are some of my concerns / questions:

      1) Are the standard Windows interprocess communication mechanisms accessible through Flex? (COM, pipes, thread msgs, etc) ??
      2) Is the added layering complexity (Flash Player / browser) too much burden to impose on a realtime GUI?
      3) Can you isolate different pieces of a GUI into separate threads? (this may be necessary for concurrency issues between user / controller software, both of which may be changing what's in the GUI, although a different mechanism may be employed to avoid this altogether)

      any input would be appreciated....

        • 1. Re: Realtime apps in Flex
          Ansury Level 3
          Well here's what I'd say...

          1) I have major doubts if you're talking about processes running on the client-- Flex normally runs in a web browser, so it's subjected to the same types of strict security limitations a browser normally enforces. You might be interested in running Flex inside AIR (aka Apollo) so you don't need a browser, but I still kinda have doubts. The server on the other hand could be implemented in alot of things, so that'd probably be a yes depending on what you're using. --I'm not sure how hard it'd be to implement a C++ server to interact with Flex, though. Usually it's Java or .NET, I'd say. (Just a warning since you mentioned MFC.)

          2) Hard to say, you'd probably have to run some speed tests simulating how fast you need your updates to be. Flash 9 is supposed to be much faster than 8, but if you're talking about updating your view REALLY fast, doing alot of drawing and so on, I dunno. But it's probably fast enough unless you're doing some intensive operations. It's just a human looking at the GUI, afterall, right?

          3) No multithreading (yet) - also no way to start new processes (even with AIR, although many are complaining for this) (and some are asking for multithreading too) I wouldn't guess that you'd need this, though.

          Consider them educated guesses, others may have different opinions... a little more information about the goal might be helpful, too.