We've had swfupload working in our product for almost a year now -- up to version v2.1.0 working fine.

With the new Flash 10 upgrades that our customers are doing, we realize we have to incorporate the latest v2.2.x version, but this has so far proven impossible after almost two weeks of trying to get it to work.

The main difference between what we do and what's in your sample demos is that we don't have the swfupload button on the main page -- we have it on a dojo dialog (which is served up by a jsp, though I don't think that should matter), and the dialog is not loaded until after a user first clicks on a button to bring it up.

Consequently, we've had to move the code that initializes swfupload (i.e. creates a settings object and calls new SWFUpload) from the onLoad section of the main page and we have to wait until dojo loads the dialog from the jsp before we can initialize. That's because the "button_placeholder_id" needs to refer to an already-existing DOM element, and until the user first loads the dialog, that DOM element doesn't exist yet.

The dialog itself has two versions of itself, a "graceful degradation" version that uses the plain browser's input button for single-file upload, and a "batch upload" version that uses swfupload.

What we used to do was rely on the swfupload_loaded_handler function being called, which would set a global js variable indicating that the batch version should be used. Then, when the dialog got shown, there was script associated with the dojo "show" event that would use that batch variable to decide which parts of the dialog to show and which parts to hide.

Now we have to do this dance where we let dojo load the batch version of the dialog, with its controls unhidden (since the "button_placeholder_id" element needs to be visible for SWFUpload to work), and then HOPE that the swfupload_loaded_handler method gets called so we can be sure that that version of the dialog is really the valid one.

We're going to have to set a timeout or something in case neither the swfupload_loaded_handler gets called nor the swfupload_failed_handler -- in that case, we'll have to hide the batch parts of the dialog and show the single-file-upload parts.

All of this seems awfully error-prone and delicate, and will cause the dialog to "flash" in an ugly way sometimes, switching from the batch to the single-file version after it's displayed, but that seems unavoidable given this new design.

But we're not even there yet -- our BIG problem is that the swfupload_loaded_handler method only OCCASIONALLY gets called -- it's very intermittent. What's worse, sometimes it gets called more than once -- for instance, when a user hits "cancel" from the dialog, the swfupload_loaded_handler gets called AGAIN (IF it ever got called once), which complicates matters terribly.

If anybody else has had any luck using this latest version of swfupload with ajax and dojo, please let me know. I've done some searching and it looks like some other people have had difficulty with the swfupload_loaded_handler not always getting called, too.

Anyway, we're pretty stuck -- we may have to just accept that our Flash 10 customers will have to stick with a single-file-upload dialog for the foreseeable future, which is a big disappointment.