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.
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.
I have an ASP.Net web app which has a page with various GridViews shown in Jquery tabs. This works fine in Firefox and Chrome but the page is slow to render in IE. So I thought instead of loading all the gridviews at once, i'll just load them as and when the user clicks on a tab.
So I have set up a new aspx page which accepts parameters of what to show. This all works fine in all browsers and the page is now nice and fast in IE.
However, IE has come to bite me again, because as soon as the page hits a postback it generates this exception:
The state information is invalid for this page and might be corrupted.
From what I can understand this is because the GridView control that is loaded via AJAX has to be inside a <form> tag with runat="server" and this is changing the viewstate of the overall page. So when it postbacks the original page it seems to have lost its viewstate.
I then tried to turn off the viewstate in the aspx being included. Via EnableViewState="false" but this still doesnt work.
I'm confused how Chrome and Firefox are ok, but only IE is getting the ViewState error. Is there anything else I can do to ensure the sub-page does not alter the ViewState in IE?
Perhaps if ASP.Net didnt detect the browser as being IE, it wouldnt do whatever it is doing to break the page?
Set the enableEventValidation attribute in the web.config file for the asp.net application to false.
If using IIS6, make sure IIS compression is turned off.
If is possible, add OnClientClick event to button, that cause the postback, and call a function that removing added controls via ajax.
In the end, after lots of research I don't think what I was trying to do is possible.
As a work around I opted to insert an iFrame within the jQuery tabs, and then load the gridview in that. This then doesnt upset the viewstate of the parent page.
I know this is rather a trivial question but anyhow I want to know if it is solvable.
I have an ASP.NET webform page with a nested masterpage and JavaScript includes. I make extensive use of jQuery and Ajax calls. Once a page is loaded, all communication with the server is done with Ajax calls, so I don't need ViewState enabled, and this is resulting in a reduced HTML output code.
I now have to implement a page where a user can upload a file. So I used the AsyncFileUpload control of AjaxToolkitFileUpload. Once a file is uploaded, I do a Ajax call to the server to request the filename.
It all works fine but I noticed that FireBug found 10 errors per file upload between the OnClientUploadStarted and the OnClientUploadComplete events. The file is uploaded properly and the events on the client side are working too. But I can't ignore the fact that there are errors thrown so I went looking for the problem.
I rebuild the page piece by piece and I found out that this control needs the Viewstate enabled.
However with viewstate=disabled in the page directive the file size is 76.6kb, and with viewstate=enabled the size is 99.2kb.
Again, I know it is trivial and will not affect performance on the site, but it is a nice to know.
- Why does this control needs the viewstate? (I suppose because it actually post the file to a iFrame or something like that?)
- How can I reduce the viewstate and let this control still work properly?
For reducing view state and having this one control work properly, you can use leave view state enabled on your page and set the ViewStateMode to Disabled for the page and then set the ViewStateMode to Enabled for the one control that needs view state. For all other controls they should inherit the setting of the parent by default.
I have an .aspx page in which I dynamically add web controls to a panel.
The problem is when I hit the browser's back buton, it's displayed a version of the page that no longer exists on the server-side, because the controls are dynamically added.
Let's say my aspx dynamically adds Control1. From there, I click a button that loads Control2.
At this moment, if I press the browser's back button, it will display the page with Control1, but Control1 no longer exists on the server-side, so if I interact with it, some erractic behaviour will occur. Any ideas on this?
Thank you very much.
Have you tried setting the client side to not cache pages - stick this in your page load:
Response.Cache.SetCacheability(HttpCacheing.NoCache)
(Think the syntax might be slightly off, but you should be able to figure it out)
Have you tried with removing temporary files and restarting browser. Your page might be cached in browser.
I'm hoping someone has seen this before because I can't for the life of me find the problem.
I'm trying to do the old "fix the back button" thing in an application and I think i have a pretty decent approach, the problem is that it relies on the application not calling page_load when you hit back and instead loading the cached version of the page.
On about 60% of my pages that's exactly what happens. It loads the cached version and all is well. On the other 40% when i hit the back button page_load calls, forcing a refresh. For reference the call to page_load is NOT in a postback.
Even stranger is that this only occurs in IE (6 & 7). In firefox page_load never gets called.
I am using ASP.NET Ajax framework on both types of pages. Anyone seen anything like this before?
--Update--
After investigating a bit more I'm finding out that when i use the search to navigate from one page to another the application behaves differently for different pages. On the broken pages the page_load gets called twice, the search gets called twice and in fiddler that turns into 2 different redirect postbacks the second of which has no-cache set.
On the working page page_load and search only happen once and it immediately redirects.
That second Response.Redirect is causing the issue. Still not sure why that's happening though.
Check what the server is returning for the cache-control http header, then try setting Response.Cache.SetCacheability()/ use the output cache page directive on the pages and see if the server is saying that the pages should be cached.
if you are using ASP.NET AJAX why not using the History server control object?
replacing History, the back button will go to the link you want.
try this