Question

in my project, I let users pick pictures using the FileReference class. I then load these pictures into their .data properties, using the load() function. After this I perform some local manipulation and send them to the server.

What I would like to do, is to be able to iterate over the picked FileReferences again, load them into .data properties, perform different manipulation and send them to the server once again. I know that I should be able to do this from user-invoked event, that is not an issue here.

Problem is, once the FileReference is loaded for the first time, I can not unload it in any way, and I can not keep the data for all the pictures in the memory because these are huge.

So I guess there is only one thing I can do, which is performing a DeepCopy on the FileReference… Then I could load the first version, scrap it and use the copy for the second ‘run’.

I tried to use ObjectUtil.copy, but when I access e.g. .name property of the copy, it fails with:

Error #2037: Functions called in incorrect sequence, or earlier call was unsuccessful.

at flash.net::FileReference/get name()

the relevant snippet:

registerClassAlias("FileReference",FileReference);
masterFileList.addItem(FileReference(ObjectUtil.copy(fr_load.fileList[i])));
trace(masterFileList[i].name)

Is it true that there are some protected properties of FileReference class that prevent it from being copied? If it is so, can I sidestep this somehow? Or is there any other solution to my overall problem?

I appreciate any hints/ideas!

Answer 1

I was trying to do almost exactly what you were doing, and I almost gave up after reading some of the answers, but I think I found a way to do it. I’ve found that if you have a FileReference object and call load() multiple times, it will work, but the main problem is that you’re keeping the high-res bytes in memory after the first load. As you’ve mentioned, for people who don’t know image processing, this is a big no-no.

The way to get around this is that after your first load(), you need to call the cancel() method on FileReference. From my testing so far, it looks like that will clear out the bytes in the FileReference, and load() will still work if you call it a second time later. Just a word of caution, this isn’t explicitly-defined behavior in the API, so it is definitely subject to change, but it may help get you where you need to go in the mean time.

Hope that helps.