AjaxFileUpload | A jQuery plugin that simulates asynchronous file uploads | File Upload library

You can change it this way:

You need to add display: flex; to the div in which the input is placed, and to change the flex-direction: row; so it will display them in row

A good article about flexbox is at: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Ok, after changing browsers to Chrome I was able to see more of the error. It was for file type not allowed. Strange, but I defined the filetypes in my config file and it is working now.

A 500 error indicates that a request was made to a web server and it could not handle it. It will be tricky to find the root cause, as the issue could be front-end, back-end, environment (web.config / app pool settings) or an issue with DevExpress.

Therefore you should run the code in isolate. For example: create a blank aspx page (no Master Page), which contains the AjaxFileUpload and has empty function/methods. If this works, then add the bare minimum code to save an image (to a temp folder). If this works, then copy code across bit-by-bit until you can create the error.

Alternatively add some logging to your back-end code. It looks like you have a try/catch that hides exceptions. If there's an error then the variables results is returned as null. It look like MultiUploadComplete() doesn't checks for success, but merely the size of the file?

Alternatively re-write the AjaxFileUpload. It's not well supported and modern JavaScript, HTML and web browsers means that it's a lot easier to implement.

Take a look at https://www.smashingmagazine.com/2018/01/drag-drop-file-uploader-vanilla-js/. This article shows how to create a mutli-file drag & drop uploader using pure JavaScript, HTML5. You'll need to create an end point, preferably using a WebApi or generic handler (if using an older version of asp.net)

As a simple proof of concept. I've put together an aspx page, which post images to an api. It sends the files individually at once for performance (but you can do it all as one request). The main thing to point out is that theres no third part libraries and you have flexibility to change the look and feel of you file uploader.

ASPX code

There is another jQuery plugin that relied on creating an iframe with src="javascript:false" and it seems like chrome 83 doesn't like it anymore (https://github.com/jquery-form/form/issues/571). It looks like (as per the jsFiddle posted there) chrome 83 block the call when using that src attribute value (I have verified it myself with Chrome 83.0.4103.61-1) but dones't block it if the src attribute value is about:blank.

As per the source for the plugin you are using, it creates an iframe with the aforementioned src attribute value (https://github.com/davgothic/AjaxFileUpload/blob/master/jquery.ajaxfileupload.js#L99), and thus the issue. Changing that line into this should solve the issue:

Ok, I have a few minutes.

If you have a bunch of text boxes on your screen. You fill them out. (no postback has occured yet). So, ANY server side code that runs will NOT have use nor see nor be able to get use of those controls.

So, you enter some stuff into text boxes. You then select a file to upload. You then hit the upload button.

Now, your 3 server side events will run. But the WHOLE idea of AJAX is you don't have to do nor want a page post back to have occurred. And a page post back has NOT occured!

So, now when the 3 server side events (from ajax file upload run), we have:

Start of upload event - server side runs. But again, that code in the form behind will NOT have use of any controls changed.

Single file upload compilate - your server side event code runs. But again, due to no post back having occurred - then any control changed or text entered into controls is NOT available yet.

Final all files upload event - again server side event code runs, and again you can't get or use any controls on the form that changed.

Several solutions:

Any text boxes, or data entered or changed? You need some kind of "ok buttion", and that button does the post back - in that routine, you THEN turn on (display) the up-loader.

Now the user can select file(s), and start the upload. For the 3 ajax events (start of up-loading), single file done, and then all done event can all run server side with use of your controls.

So, just keep in mind that you can enter a bunch of data into the form, and then use the up-loader (select files, then upload button). For this whole process no page post back occurs

Worse? If you put a submit button on the page, and the user has selected files, and then decides to hit the post back? Well the ajax uploader does NOT persist the files selected during a post back. This is why I strong suggest you hide the up-loader (can't use visible, you have to use style).

The most simple solution is if you have a group or bunch of controls on the form that you need to set or will have data/changes made before they start a upload?

Put the group of controls in a up-date panel. And set auto post back for each of the controls. So, any control you edit will now cause a post-back. Now, such data is available in server side code. (and that includes the 3 ajax up-loader server side events).

Do keep in mind that this up-date panel will result in what is called a partial post back (the on-load event will fire).

So, the behavior you are seeing is not a surprise at all. You also can NOT hide/show or change values of controls in the 3 up-loader events because as noted, you will be changing values of controls, but the page has NOT been posted back. If you attempt to change controls in the 3 events, whatever you do will be lost if/when you/users do eventually post back the page. Remember, you have a stateless web page on the desktop.

If that stateless page has not (yet) been posted back, then the 3 ajax server side events can't see the client side browser controls at this point in time. And if your change controls in those 3 events, you are changing the controls sitting server side, but the web page is not going to be updated.

So, you either have the controls on the page do a post back BEFORE they select files and start up-load. As noted, I often "hide" the ajax file up-load. Let user enter some stuff, and then have a "ok - now lets up-load files". When they click that button, your server side code runs, you do whatever, and then turn on (display) the ajax up-loader. At that point then ajax upload events (the 3 server side events) can run, and that code now has a posted back copy of the client browser.

Now, assume the very last ajax event (all files uploaded) has occured. You can now try and modify controls on the page, but the page is still sitting client side. It has NOT been posted back. And you not going to be able to post that page back between the start of the up-loads, and when you finish. If you simply run a bunch of code in the final event and try to update controls and values on the page - you can't!! Because no post back has occurred and the controls and their values are still sitting client side.

Another way to achieve this goal is to use a client side javescript event tied to the LAST ajax event (all files done). However, that means the 2nd event (one file done, and save-as file) will NOT have use of controls if you start the up-load BEFORE the page has been posted back.

So, this means that if you going to use controls during the up-load (start to finish events), or run code in that final event that modifies controls? You need the page posted BEFORE you run the up-load process.

You can try can change all and any controls with code in that 3rd final server side event, but you modifying controls in the server side browser copy. You not see ANY changes take effect. It will thus seem like you cant modify anything.

So, in a good deal of up-loads? Well I want something to occur AFTER all is said and done. This means that the 3rd final event of the up-loader needs a client side event (and it will have a __dopostback() js command. The up-loader is VERY well built in that the client side JS events ONLY fire AFTER the server side events are complete.

So that final post-back trick/tip is ONLY of use if you want something to occur after all is said and done. But this tip don't help you get at controls in the 3 events, and as noted, unless you send the browser page back to the server, then any code you run server side will NOT show up in the browser. In other words, if you want some updates, or message boxes on the screen to update at the end of the load? You cannot use that 3rd final ajax code stub. You have to do a post back BEFORE you attempt to modify anything on the page.

(else you be modifying the server side copy of the browser without having posted back the client side browser copy that is "different" and not the same.

So, those 3 events can't modify any controls, since the page not been posted, and when you eventually do post the page, what controls you modify will be lost/overwritten when the client side browser post back occurs.

So you not losing the ability to modify controls on the page in that 3rd last event, but you modifyng a copy of the server side page - and you never see the changes.

So, with a standard asp.net buttion: we have: Post back (browser page goes to server) Your code (any code behind) can run, can see, can grab/set/see/change any control on the form. Now browser is re-sent back to client and displayed. (so you can see your server side code changes in those controls.

With the ajax uploader, no page post back has occured, and no re-rendering of the browser will occur. (those controls and events don't cause a post-back). So, you can't run server side code to change things, since you don't have a copy of the client side. And even if you do modify controls, no page is sent back to the client side to re-display.

So, based on the above asp.net model and code behind? You can't change controls unless your server side code runs as a RESULT of a post-back.

So, either get your post back all done and wrapped up BEFORE uploader runs, since those 3 server side events can't modify controls, and will not see client side changes unless you do/did a post back BEFORE the upload starts.

Just put auto-post backs in the controls. But then auto post backs for the several controls does cause a whole page post back. So, you can "mitigate" this by placing the group of controls in a update panel. Or, as noted get all your controls loaded up and set with a post back that THEN displays the up-loader for the user to start.