I am building a sort of hybrid of your NeatUpload and SWFUpload (http://swfupload.mammon.se/index.php) - this will allow users to select more than one file at a time and pass that to the server - my question is is NeatUpload more dependent on the display side to split the file up or does the httphandler do more of that -
I have (briefly) looked at most of the code and cant seem to get a handle on what is happening in it and where
If I want to pass a large (360MB) file from SWFUpload to your http handler is there any real problems or do i need to wrap that with some extra code?
I realize you may know nothing of SWFUpload or want to learn anything about it but if you coudl kind of describe how your control and handler works together it might help me sort them out to work together
SWFUpload looks really nice. I've been looking for an open-source flash solution to integrate with NeatUpload. I haven't actually tried it yet and probably won't be able to right away, but I *think* it should be pretty easy. Try the following:
Install the NeatUpload development snapshot (currently NeatUpload-trunk.439.zip). You need to use the the development snapshot to access the uploaded file via Brettle.Web.NeatUpload.UploadHttpModule.Files.
When you instantiate SWFUpload on your form, pass "HandleSWFUpload.aspx?NeatUpload_PostBackID=anything" for the upload_script parameter.
Create a HandleSWFUpload.aspx page on your site. It is the page that will be receiving uploads from SWFUpload. It don't think it needs to have any controls on it. It's Page_Load() method should be called once for each file that SWFUpload sends.
UploadHttpModule.Files is only available in the development snapshot. In NeatUpload-1.2.x, you need to put an InputFile control with an ID of "Filedata" on the page that SWFUpload uploads to. Then, that InputFile control will contain the uploaded file on postback.
Maintain a server-side mapping (in the application's cache or application state) from postbackID to the information you care about (e.g. user ID, files uploaded by that user, etc). When rendering the page before postback, generate a unique postbackID and add an entry to the mapping with that index, filling in whatever info you know at that point (e.g. user ID). When the postback (i.e. upload) occurs, save it under a unique name that has nothing to do with the query string, and use the postbackID to lookup the entry in the mapping and add the generated filename to that entry.
Hello. I too have dove into the world of using Flash for uploads due to the enormous GUI potential. I actually wrote a fire-fox like flash uploader thats as smooth as a desktop application progress bar.
However the support/tracing of flash uploads is lax. Often times the upload fails for no reason, stops, or returns "IO ERROR" with no explanation. The server was not restarted (im logging these events) and I can find no way to see what caused the upload to fail.
Based on what I read below (even though that was a couple versions ago) I believe I can easily implement the same thing using NeatUpload to handle the request.. But my question is why?
Will neat upload better handle the incoming file preventing the IO/Errors? Will neat upload better handle session/application restarts? Will neat upload better handle the incoming bit stream making it less prone to errors? What is the major advantage to neatUpload vs HttpPostedFile? as HttpPostedFile supposedly streams direct to disk anyway..
I have had your product installed for years just never implemented because of the GUI issues..
NeatUpload's UploadHttpModule primary job is to allow the server to monitor upload progress so that it can be displayed to the user. Flash is capable of monitoring upload progress from the client side, so that capability of NeatUpload's UploadHttpModule isn't really needed if you are willing to require users to have Flash.
I should probably point out a few other potential advantages of NeatUpload:
NeatUpload's controls behave like the standard ASP.NET FileUpload or HtmlInputFile controls in that they provide access to the uploaded files as part of a form postback. Flash uploads each file in a separate request, but NeatUpload does the work of keeping track of the individual files and providing access to them from the browser's form postback.
If you have a web garden or web farm, the different requests from Flash could go to different application instances. Assuming it is configured properly, NeatUpload shares the upload state across those instances so that it can be accessed from the instance handling the browser's postback.
NeatUpload's client-side script ensures that an upload is not started if that page doesn't validate or the user clicks a button that is not suppose to start the upload.