I'm experiencing a very strange problem...
I have a regular ASP.Net webpage with a page_init and a page_load function. It is my understanding(from everywhere I look) that page_init gets called on the first page load(as in, not ever called in a postback) and page_load is called anytime something happens with the page.(It is very hard finding any info about this except for dead links and stuff about the page life cycle)
Well, I have an update panel containing other update panels and other assorted controls. Anytime I edit one of these controls, an async postback happens but instead of only page_load being called, page_init is also called which isn't suppose to happen(and didn't happen before a big codebase change)
So I would like to know anything that might cause this behavior or just if my idea of how page events are called is wrong.
I think you have the wrong idea of the page load life cycle. The OnInit event is called on EVERY request. Having the Page_Init method in your code behind is a shorthand way of wiring up the pages OnInit event.
Now I believe that you are confusing this with the "IsPostBack" property which will be set to true if a page posts back to itself i.e. when you click a Button etc. My guess is what you need to do is add an if statement in your Page_Init method i.e.
if(!IsPostBack){
//Do something to to update the UI
}
Page_Init is definitely called on every page hit, postback or not, exactly the same as Page_Load.
The misconception that Page_Init doesn't get called on every request seems to be a common one.
Are you certain that this wasn't happening before your "big codebase change"?
My suggestion is that you create a simple example of what you're trying to do on a brand new scratch page based on these rules..
http://msdn.microsoft.com/en-us/library/ms178472.aspx
Keep adding complexity as you have it now until it breaks..
It would be difficult to diagnose your issue without the code..
Your Page_Init as well as Page_Load both methods should be called each time.
Related
I want to prevent button_click event in page refresh.
I have searched but can not get any solution relevant for me.
I have found this one:
http://www.dotnetspider.com/resources/42823-How-Avoid-Re-Submitting-Data-Page-Refresh.aspx
But i do not need to go inside button_click event in page refresh.
Response.Redict("") also not relevant here as i am returning label text after succesful button_click.
What you looking for is not so simple.
The solution you can use for sure is the Post/Redirect/Get design pattern
or use some code that tries to detect the refresh of the page on:
http://www.codeproject.com/KB/aspnet/DetectingRefresh_.aspx
http://dotnetslackers.com/community/blogs/simoneb/archive/2007/01/06/Using-an-HttpModule-to-detect-page-refresh.aspx
I have an ASP.NET user control with a button, and I want to add it to the page when the user clicks a button from another user control. I have created an event handler to the first user control to handle it from the page and add the second user control to a page. Everything is working normally, but the button on the second user control doesn't respond to the event.
I place the second control on RadAjaxPanel
Note: When I add the second user control at design time its working fine.
All dynamically created controls should be added by the end of Page_Init (though sometimes you can get away with them added by the end of Page_Load).
If you're only adding them based on a button click event then you've done this in the event handers which fire AFTER Page_Init and Page_Load in the lifecycle - This is why your events don't fire and why it works fine when you add at design time.
This is because when a button is clicked on the second user control - the whole page lifecycle starts again. The page goes through Page_Load and Page_Init first and your control doesn't get loaded here. So, when the page lifecycle handles the "handle postback events" part, the control no longer actually exists, so the event doesn't fire.
Conversely, when you add at design time, the control exists in Page_Init and Page_Load so is able to handle the postback events from the user control because it already exists in the control tree - if this makes sense.
You need to think how you can restructure so they're added by the time Page_Load has finished at the very latest or it won't work. Without code samples or more detail it's hard to suggest exactly how you might do this. One possibility would be to set it visible instead of loading it outright - but if the control does some 'heavy lifting' on load like database hits or API calls then this might not be suitable for you.
I did something similar. What I did was to load some controls dynamically based on a selection from a DropDownList. If you have a method which loads the control for you, let's call it LoadControls(), then you can do something like this:
DropDownList_Click {
ViewState("LoadControls") = true;
LoadControls()
}
By setting the ViewState variable, you can then indicate Page_Load to load the controls on future postbacks:
Page_Load {
if (ViewState("LoadControls") == "true")
{
LoadControls();
}
}
This has the effect of then loading the control on-the-fly when the event first happens, and then at future times in the lifecycle.
I have usercontrol x in a page, within usercontol x is usercontrol z. I need to do something to usercontrol z after an event fires in usercontrol x. I understand this is very generic, but it just lays out a simple premise for my issue.
Is there a simple way to get a list of all events that fire in the page lifecycle whether I am subscribed to them or not to find out what events fire between Event A on the page and Event B on control z? I would think that there would be something like this when page tracing is turned on, but I don't see any events listed. I imagine that it would be something that the pipeline could generate, maybe I could use reflection to get a list?
I found this topic hard to search against in general, maybe I am using bad keywords...
I did find an old project on codeproject.com, but I was hoping that there would be something more elegant available by now.
*To clarify, I'm looking to generate a list after a postback of every potential event (subscribed or not), in firing order from init to unload, of all controls on a page.
THIS POST: Tracing all events in VB.NET
gets me a little bit closer, however these are lists on a per control basis, not in chronological order.
Enable trace with <%# Page Trace="true" %> in page attribute. that should display life cycle events in sequence.
Well if you're just looking to see what the events are in general, and in what order they fire, check out this article. As far as getting them...well, that depends on what you mean. It could be as simple as getting them through reflection:
EventInfo[] events = this.GetType().GetEvents();
The ASP.NET Page Life Cycle Overview on MSDN lists all of the events fired by a Page from PreInit to Unload. Most of these events fire on any class that inherits from System.Web.UI.Control as well.
Update
Now that I understand your intention better, one possible solution would be to loop through the events of every control and assign an event handler that logs the calling of the event. There is at least one way to retrieve all of the event handlers assigned to an event, and it shouldn't be too difficult to adapt that code to assign an event handler instead.
I am dynamically generating controls, and sometimes I want to create a control and have it ignore the viewstate. For example, sometimes the user has clicked a button indicating they want a different form loaded, so the control tree I generate on postback is different from the original control tree. This is fine, except when I call Controls.Add then it tries to load the viewstate form the old controls into the new controls if the control tree structure is similar, and I want them to instead ignore that viewstate(and also ignore the postback values for input controls as well).
Can I do something like set the IDs of the controls or something that would allow me to conditionally prevent them from getting the viewstate/postback data of the previous request?
Edit: If I let the user of the control load the form on demand in postback handler, the postback data is not applied when I call Controls.Add(this really seems like a flaw in ASP.NET, because I would think if you're going to apply viewstate data "after the fact" through Controls.Add, it'd seem you would then apply the postback data automatically as well after the viewstate data is loaded). The real problem I run up against is my control is very dynamic, but the user of my control can't really tell it what to do until their postback handler fires, because one of the things a user can do is select different forms to be loaded via some link buttons. So it's not until the postback handler runs that they know what the uesr requested, and thus can ask my control to load a certain form. So I have to ask them to do convaluted things like saved the formID that identifies the last form to a session variable, and in OnInit they tell my form what the old formID was via a property. My control then loads the form in OnLoad so that it can consume the viewstate and postback data, and later in the programmer's postback handler, they can choose to clear the form and load a different one if they want.
Edit2: FYI Generating IDs for each control unique to the form works great, so I thought I could eliminate the pointless loading of the old form until the programmer requests a form be loaded in his postback handler. But as I mentioned above, what I found was that loading the form after postback data handling has occurred means that data is lost. Whereas viewstate gets loaded via Contorls.Add, playing catch up in the page lifecycle, it seems postback data does not! So it seems I am defeated at every turn.
You're going to avoid problems if you play along with the control lifetime. Basically, whenever you have a control that renders, it's best to ensure that control is recreated on the next postback, even if you aren't going to need it anymore. The first goal of a postback should be to restore the previous state -- only THEN do you make changes to it.
I described it best in this answer:
Wrong state in Server Controls with same ID's when dynamically adding UserControl to UpdatePanel
Giving the controls different ID's would certainly prevent ViewState from being loaded, that would be one way.
You may also be able to manipulate the ViewStateMode property of your controls by setting it to "Disabled". I'm not sure if this prevents it from loading (it definitely prevents them from saving viewstate), but you could try it.
Have you tried just calling controls.clear prior to adding in the new ones?
UPDATE
I'm starting to believe that you are generating the controls at the wrong point in the page lifecycle. What is your flow?
You must be generating dynamic controls on postback in pageload:
protected void Page_Load(object sender, EventArgs e)
{
--Generate Dynamic Controls--
}
You need to do it like:
protected override void OnInitComplete(EventArgs e)
{
base.OnInitComplete(e);
}
protected void OnInit()
{
--Generate Dynamic Controls--
}
protected void Page_Load(object sender, EventArgs e)
{
}
I'm setting a HTML string value to webbrowser.DocumentText. Problem is, sometimes it worked and sometimes it hangs up and not go through the documentcompleted event. what might be the problem?
Please reply, asap..
Thanks,
Jepe
Just a thought: With all the web-'dynam-ism' nowadays, a page is never really in a 'completely-loaded' state. After DocumentComplete, the OnLoad event of the page is fired, then any scripts placed in such an event are fired, and then javascript timers may be used to initiate download/upload of some resource, or a change in page using AJAX, etc.
I believe AJAX calls could cause all kinds of unseen problems with your WebBrowser control; because AJAX can cause multiple Navigating() events to fire during the loading of a page. And for that reason your app would experience multiple DocumentCompleted event fire on that page.
A possible solution could be to monitor the page changes and attempt to find out what possibly got changed. And to do this you may need to look into Notify method.
Called by MSHTML when a change occurs
in the contents of the markup
container with which it is
associated.
This and this discussion may help you coming up with something like following:
HtmlElement target = _webBrowser.Document.GetElementById("somedivthatwillbepopulatedbytheajaxrequest");
if (target != null)
{
target.AttachEventHandler("onpropertychange", new EventHandler(handler));
}