I have a very strange problem -- I am trying to download a
simple file from a server, using virtually identical code to what
is in the FileReference.download() examples. My code executes
flawlessly, I get the browse window to select the location to save
and name of the file, as expected. I click "Save" in the file
dialog, and the window disappears -- but no file. I know my URL is
right, because I can test the URL from the browser, and I get the
file back. But here's the even weirder thing: I threw TCPMon in
between Flex and the server, and discovered that the
FileReference.download() method isn't even sending a request to the
server. If I try the exact same URL through a browser, TCPMon shows
both the request and response. But Flex never registers a request
Help! I have 100% error free code that follows the
documentation examples but doesn't request or download the file.
I found the answer to my problem, but now I want to know WHY
this is, and if it is considered a bug by Adobe -- if anyone out
there has an explanation, that would be great.
I implemented the full set of event handlers, and guess what
-- not only was I not getting any HTTP request being made, but I
also didn't get any event callbacks. Bottom line, I think I found
an Actionscript bug.
The answer to the $64,000 question is this: when the
FileReference object goes out of scope (I had it declared locally),
because the download() call is asynchronous, it doesn't call event
handlers or make a request. It must be garbage collecting it. So
you have to have your variable as a member, not a local variable.
Weird. I find no other objects in Actionscript work like that. I
wonder if it has something to do with the fact that the call
crosses the native boundary (because it is leaving the Flash
sandbox, and interacting with the browser/native OS.
To me, that's like prematurely killing a thread before it has
completed processing just because it has no parent object with a
reference to it. In general, most rules for garbage collection I've
seen in various platforms require either a parent object or thread
of processing to prevent cleanup.