Ajax FileUpload is hijacking the aspx - asp.net

Question

I have a very simple page I'm intending to use to show the contents of a network file. The target file is brought in with the Ajax Toolkit AjaxFileUpload control. It works, and I can see the file contents when stepping through the debugger. The offending behavior, however, is that once the file is uploaded, the codebehind loses all ability to update the page. I cannot write the file contents to a multi-line TextBox. I cannot even update a label on the page. Neither can I write hard-coded "Test Text" to the TextBox or Label.
There are no errors or exceptions throw. The code runs to completion without writing the contents to the TextBox.
<h2>
Encrypted File Viewer
</h2>
<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>
<asp:Label ID="ViewingLabel" runat="server" Font-Bold="false" ForeColor="Green"></asp:Label>
<br /><br />
<asp:Button ID="UnauthorizedExitButton" runat="server" Visible="true" OnClick="DoExit" Text=" Exit " />
<br /><br />
<Ajax:AjaxFileUpload ID="AjaxUploader" runat="server" OnUploadComplete="FileOpen" width="800px"></Ajax:AjaxFileUpload>
<br /><br />
<asp:TextBox ID="Viewer" runat="server" Width="800px" Height="500px" TextMode="MultiLine"></asp:TextBox>
In FileOpen()
string tempPath = Path.GetTempFileName();
string tempPath2 = Path.GetTempFileName();
AjaxUploader.SaveAs(tempPath);
myStrUtility.DecryptFile(tempPath, tempPath2);
Viewer.Text = File.ReadAllText(tempPath2); //Fails
// For testing - Debugging
ViewingLabel.Text = File.ReadAllText(tempPath2); //Fails
Response.Write (File.ReadAllText(tempPath2)); //Fails
I'm completely baffled by this, since I can see the decrypted contents of tempPath2.
Thank you in advance for any insights you can offer.

Answer 1

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.