No Event.COMPLETE for FileStream.writeUTFBytes()?

[midimid]

Why is it that FileStream.openAsync() does not dispatch Event.COMPLETE when writing a file? If the file was really big (its not, but still...), how would I know when its done writing?

What if, for instance, I am writing a bunch of files in succession and I don't want to write one file until another one has already been written. Without an Event.COMPLETE I don't know when to close the stream.

[fx.barrett]

I have the same problem but with FileStream.open(); and not only with the COMPLET event. It simply won't dispatch any kind of events. Anyone got any ideas on this ?

EDIT: I did run over this: http://bugs.adobe.com/jira/browse/SDK-12358 and from that, things aren't looking too good. If that is true, then we can't listen for an actual COMPLETE event although in theory we have one... Really bad, sad and weird at the same time...

[midimid]

Any filemode other than write absolutely sends events for me.

For writing, in the end, I just made a function that writes data with openAsync taking a filename and file data as arguments. Its sort of a "call it and forget about it" function and I'm just making sure that anything I'm writing is small.

Fortunately, for me, that'll work fine for now.


private function saveFile(filename:String,data:*):void {
var dataFile:File = File.desktopDirectory.resolvePath(filename);
var filestream:FileStream = new FileStream();
filestream.openAsync(dataFile, FileMode.WRITE);
filestream.writeUTFBytes(data);
filestream.close();
}

[Billy Goat Karaoke]

Hi

I had a similar problem (now solved) when writing a file to the local disc, then uploading it. If the file was over about 200k, it didn't get written fast enough before the uploading would take place, and as there is no working 'COMPLETE' event for FileMode.WRITE, I did it this way (I'll use your example midimid):

private function saveFile(filename:String,data:*):void {
var dataFile:File = File.desktopDirectory.resolvePath(filename);
var filestream:FileStream = new FileStream();
filestream.open:)(dataFile, FileMode.WRITE);
filestream.writeUTFBytes(data);
filestream.close();

:) filestream.openAsync(newFile, FileMode.READ);
filestream.addEventListener(Event.COMPLETE, readyToUpload);

}


I changed the openAsync at smiley 1 to 'open' - this stopped input/output reading errors.

Then I added the READ code at smiley 2, plus an Event.COMPLETE for when the file had been fully READ. THEN I ran my upload function.

It works whereas before nothing would upload, or Flash would crash - although I am yet to test it on a very large file.

I think it works because Flash won't run the READ until the WRITE is complete. So I'm basically using the READ as an event listener for the WRITE, then using a proper event listener for the READ to progress to the rest of my AS3 code.

Hope this helps. Please let me know if Adobe have already fixed the WRITE Event.COMPLETE problem!!!

Cheers

Shaun

[OMA]

Maybe I'm overlooking something, but in Billy's example, since he's writing synchronously, why reopen it with openAsync only just so an event gets fired?

Wouldn't it be much easier to replace the bottom two lines with a direct call to readyToUpload()? After all, that function call wouldn't be reached until all the bytes have been written (since it's a synchronous file write).


Anyway, using the OUTPUT_PROGRESS event you can detect when an asynchronous file write has been completely done. Like this:

filestream.addEventListener(OutputProgressEvent.OU TPUT_PROGRESS, outputProgressHandler);

private function outputProgressHandler(event:OutputProgressEvent):v oid
{
if (event.bytesPending == 0) { /* Now the file is completely written */ }
}

In my tests, this event is always fired for async writes with no problem.

The function outputProgressHandler will be called several times throughtout the async write process (each time something is written).

If the file is very small (such as a short config file), it will only be called once with a bytesPending value of zero. If the file is big enough, it will be called several times, with different ever decreasing values of bytesPending, until the last time, when bytesPending equals zero.

Hope this helps.