This content has been marked as final. Show 4 replies
is the operating system locking this file?
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.
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.
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.
My protocol spec is below, just on the offchance that someone may find it useful:
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: