4 Replies Latest reply on Oct 12, 2007 7:30 AM by Bob_Robertson

    Communications with .SOL files

    Bob_Robertson Level 1
      I have created a disgusting little hack. W needed to talk to the serial port from within Flash. We can't use Hernando Barragan's socket server because our clients' IT people might complain about having to work around it in their firewall. Frankly, I can't blame them--who would want to compromise their own defenses, even given additional functionality?

      Anyway, I noticed the Shared Object, and thought Aha! Finally, a way for me to talk to the computer without having to use the network! The idea was that a client program would be watching the file for changes, and would communicate with my Flash code via this file. A shared medium usable by multiple parties is a means of communication, so it should work. Well, I write up a quick and dirty protocol, implement it on both sides, and test my code. Everything can read the file, detect changes; it works nicely.

      I go to the next level, which is figuring out when both parties are willing to exchange information. This, too, works well, and after some minor debugging tweaks, it's good to go.

      Finally, I get things to the point where I can change the contents of a variable in the shared object file, and the local program will detect the change and send the contents of that variable to the serial port. The trouble is that after I write to the serial port, the Flash player apparently can't change the contents of the shared object file. I've tried flush()ing the shared object, I've tried deleting it and recreating it. I'm out of ideas.

      I realize that the above was enormously general, but would anyone care to speculate on what might be going wrong?

      Many thanks,
      Bob Robertson
        • 1. Re: Communications with .SOL files
          kglad Adobe Community Professional & MVP
          is the operating system locking this file?
          • 2. Re: Communications with .SOL files
            Bob_Robertson Level 1
            Actually, after some experimentation it looks like changes made to the shared object file aren't being reflected in the Flash Player's view of the shared object. Ferexample: I start the flash app, and use it to reset all the fields. I then toggle a boolean in the shared object with a 3rd-party hex editor. If I look at the fields again, its value hasn't changed. If I delete the sharedObject instance in flash and reinstantiate it, its value hasn't changed. If I restart the Flash Player itself, the value is changed.

            Things I have tried: deleting and recreating the sharedObject instance in flash, deleting the sharedObject instance and loading the data into a new sharedObject instance. I'm beginning to think that since the Flash Player doesn't expect other programs to be editing the file, it just caches the contents of that file and changes the cache. At this rate, I might have to edit the file, copy its contents to a new file with an incremented file name, and then let my flash app figure out the most current file name.

            How could I tell if the OS is locking the file? I'm developing on Win2K SP1.
            • 3. Re: Communications with .SOL files
              kglad Adobe Community Professional & MVP
              if the os were locking the file, no program would be able to access the file. this should only happen during the time you're actually writing to the file. from you last explanation, it's clear that's not causing your problem.
              • 4. Re: Communications with .SOL files
                Bob_Robertson Level 1
                Success! It turns out that any modifications made to the SOL file by an external program aren't reflected in the sharedObject instance at all until the flash player restarts. If a new SOL file is created while the flash player is open, and the flash player then accesses a sharedObject with that name [i.e. sharedObject.getLocal("newFile")] its values are detected as null.

                I conclude that my earlier theory was correct: the flash player, upon startup, looks in the appropriate directory for its shared objects once and loads their contents into its memory. Any changes then made to the data in the shared object are not written until that instance of the flash player closes, or unless the code calls sharedObject.flush(). Therefore, a sharedObject is a one-way communications channel: it can change the contents of the publicly-accessible file at will, thereby allowing communications to be sent to external programs. External programs, however, cannot reply.

                I did investigate cookies, and accessing them via javascript and ExternalInterface or getURL("javascript: foo()"). It turns out that browsers do the same thing with cookies that the flash player does with shared objects: it writes changes to them, but doesn't load them from a file to access their contents. Therefore, cookies are also a one-way medium. They are, furthermore, less desirable than shared objects, because a) they are placed in OS- and browser-dependent locations, b) the file format is browser-dependent.

                My protocol spec is below, just on the offchance that someone may find it useful:
                Field List
                toggle (Boolean)
                nFromFlash (string, 1 char)
                bufferFromFlash (string, “0”-suffix-padded to 32 chars)

                To Send to Serial
                Flash pads string to be sent with “0” to 32 bytes, writes string to field.
                Use hex representation of numbers, for clarity: “00” for 0, “10” for 16, etc, for bufferFromFlash and nBytes
                Flash sets value of nFromFlash (in hex)
                Flash inverts value of toggle.
                Flash flush()es the shared object to immediately write to file.

                Receiving from Flash
                On start, record value of toggle in variable external to parser storage.
                On file change, compare current value of toggle with old value of toggle. If different, send first nFromFlash characters of bufferFromFlash to serial port.

                The following URLs proved useful in writing a program that understands .SOL files: