I have a fairly simple aspx page (using a MasterPage) with various buttons and server-side event handlers. When I click the buttons the event handler is hit almost immediately. However, as soon as I add the following to my page:
asp:FileUpload runat="server" ID="fileUpload"" there is a huge increase in the delay between a button click and it's event handler, the fileUpload control is not used at this point.
I am struggling to find out where the delay in the process is so that I can try and bypass it. Any help is much appreciated.
Thanks.
It turns out the issue was related to McAfee DLP https://www.mcafee.com/uk/products/total-protection-for-data-loss-prevention.aspx
Whatever is added to the aspx page / viewstate by the fileUpload control caused our McAfee DLP to kick in and perform a whole bunch of checks before the page request was finally submitted.
Related
Can someone explain to me the sheer purpose of a page load? My code runs just fine without it right now in my aspx.cs (codebehind) file. I am doing very basic stuff here, so im guessing it has a lot of importance somewhere so i am just wondering what that would be. thanks for any help!
You should check about the Page Life Cycle.
The load is an event in this Cycle.
About the method, Page_load() is the method on the server side application, for an .aspx file. All code inside of this method is executed once at the beginning of the page.
Also, in the load, if the current request is a postback, control properties are loaded with information recovered from view state and control state. (Different from initialize, when you set the default values)
So, in the Load Event, the Page object calls the OnLoad method on the Page object, and then recursively does the same for each child control until the page and all controls are loaded. The Load event of individual controls occurs after the Load event of the page.
Some links for you:
ASP .NET Page Life Cycle
Page_Load and Postback
and there are a few more in Google
When I click the Button I am loading one page. i am having some controls in the page_load.
but the problem is my page_load is hitting more than once.
Please can any body explain me what could be the possible reasons for hitting the page_load multiple times.
Thanks
Is hitting Page_Load twice your issue?
Most probably its due to asp:Image or img without src defined.
To quote mbanavige of ASP.NET Forums,
if you have an img tag with an empty/missing src attribute, then the
browser may re-request the current page (or may request the default
page) why trying to satisfy the empty src for that img tag.
Another possibility that occurs from time to time is that the
page_load event has been wired up twice.
Related: page loads twice in Google chrome
This is by design. In the page life-cycle it is called on the initial request and on the postback.
http://msdn.microsoft.com/en-us/library/ms178472.aspx
ASP.NET webforms are self-posting, so Page_Load will hit hit everytime a time a post back occurs. If you would like to only execute certain code on initial page load, add the following to your Load event handler:
if (!Page.IsPostback)
{
// Code here
}
This says only execute this code if this is the first request to this page.
When the ASP.net Page is Postback the controls inside the table is disappear,
but when i click on button that has that code which cause transfer to the page:
Server.Transfer("~/Admins/EditUsers.aspx");
all controls appear easy with no problems.
Then,is there is need to make refresh to the page, or what can i do?
Thanks
A postback already performs a page refresh automatically.
If controls are disappearing, that suggests that you might not be creating them on the postback. Note that tables do not store their contents in ViewState. Is there any chance you are testing for IsPostBack in your page Load handler? If so, you must recreate the table on every load, whether a postback or not.
Beyond that, you'd probably need to provide a bit more specific information.
I've been trying to solve a problem. I have a rather slow loading set of nested datarepeaters that take a couple minutes to fully render. I need to have a cancel button.
First I tried a simple updatepanel with a cancel button in an updateprogress that performed an abortPostBack. It would hide the updatepanel but wait until the datarepeater was done before you could do anything on the page.
We have the Telerik AJAX controls so, hoping they're more advanced, I've now wrapped it up in a RadAjaxPanel. This seems to have the same issue. I've even tried firing an ajaxManager.ajaxRequest back to the server and setting a bool to try and abort the databinding, but that event isn't caught by the server until the databinding completes.
Any ideas on how to get a responsive cancel to a large set of nested datarepeaters?
I think that you can cancel the ajax request from Telerik ajax panel or ajax manager only before it reaches the server, i.e. inside the OnRequestStart client event of both by setting args.set_cancel(true).
Dick
I have a control which has an ImageButton which is tied to an OnClick event... Upon clicking this control, a postback is performed and the event handler is not called. AutoEventWireup is set to true, and I've double checked spelling etc.... We haven't touched this control in over a year and it has been working fine until a couple of weeks ago.
We have made changes to controls which load this control... so I'm wondering, what kind of changes could we have made to stop this event handler from being called? There is quite a bit of Javascript going on, so this could be the culprit too...
Edit: Some clarification... we are dynamically loading the parent control of the ImageButton in the OnLoad event of the page... if that makes sense.
AutoEventWireup is irrelevant. Is your ImageButton loaded dynamically, i.e. not written out in mark up? If it is loaded onto the page late in the Page lifecycle e.g. in PreRender then the event will not fire.
If there is a JavaScript issue your page will not even PostBack. Is that happening?
Did you give the ImageButton an ID?
I def agree with what BritishDeveloper said. I had a similar problem where I was dynamically loading controls, but I couldn't get a reference to the control using Page.FindControl("controlName") Someone pointed out that I needed to keep the page lifecycle in mind. I found out I needed to make sure to load the control in the PageInit because after doing an async postback the control was still there, but not loaded in the postback so there was no way to find it. This was all in csharp codebehind and ajax though, but I'm guessing the control isn't getting reloaded.
So, as it turns out we set the PostbackUrl property on one of our buttons in control A... this caused the event handlers for control B not to fire when a button in control B was pressed.
If you create a control dynamically. Any time you fire a postback using the new created control, you need to recreated it. Just think that your application are running at a server. How can the server hold information on controls created dynamically? Don't use Page.IsPostBack to create postback. PostbackUrl is bad solution. Workarround will be need.
I can go into a little more detail ... I just lost several hours fixing my own issue similar to the issue described here. In the course of creating some search controls, I added a pair of ImageButtons and set the PostbackUrl properties on them. A few days later while testing new code, I noticed that none of my other buttons on the webform were posting back properly. They would fire a postback, but the code-behind was behaving as if every postback was an initial page request and none of the event handlers were firing.
After several hours of troubleshooting, I came across this post. When I went back and removed the PostbackUrl from those two ImageButtons, everything went back to normal. I don't know why it was causing this issue, but the fix mentioned here worked for me. I want to add that my ImageButtons were not dynamically added ... they were in the markup and this issue still cropped up. Search your markup for any controls with PostbackUrl set ... remove that (program around it if needed) ... see if your event handlers will fire properly.