I have a MasterPage, with my Usercontrol inside a div.
I can set visible=false to the UserControl and to the containing div, and this works fine.
But the Page_Load of the UserControl is always hit.
Is this by design, or am I missing how to stop page execution going into the Page_Load method of the UserControl.
When you add a UserControl to a page it will be instantiated and added to the Page.Controls collection every time the page is executed. When you set Visible to false it basically just short circuits the rendering of the control's html so that it doesn't show on the page.
If there is some expensive operation that your control does in "Page_Load" I would key off of the Visible property to circumvent that operation.
If the control was never created, how could you tell it to be invisible?
You cant stop execution going into the PageLoad event method for a user control.
#joshperry suggestion to use Visible property to determine whether or not to do a time consuming operation in the code is a good one.
The other option would be to complete the time consuming option in the OnPreRender event method.
Related
I am using entity framework 4.0 to bind a database object to a DetailsView on an ascx control. Within the DetailsView, I have a number of asp:panels that I'd like to show/hide depending on what's happening in that person's visit.
So, the first time through the page I'm setting panelA.Visible=false in the FormView_OnLoad event, and all is well - that panel is not output in the HTML. It listens to what I'm asking here.
Once I click submit and postback, I am again checking what's going on and setting panelA.Visibe=false in both FormView_OnLoad and EntityData_OnUpdating. But this time, when the page comes up panelA is showing.
I find that I can only hide that panel after postback by setting visible=false in DetailsView_PreRender, or by binding visibility to a public variable.
I'm thinking perhaps in the life cycle the DetailsView is binding again way toward the end, and throws away my visibility settings, even though they're not bound. So to show/hide panels within the DetailsView on postback, will I always have to set visibility on DetailsView_PreRender or after?
Am I on the right track here, or is something else resetting me at the last second?
Why can I set visibility the first time through the page but not postback?
You should always make final modification of your page structure after postback processing - that is the reason why PreRender event exists. Other possible event in your scenario can be handling DataBound event but better and more clear way is PreRender.
I have a UserControl inheriting from another, and my question is simple. Does the control's page load fire first, or does the base class page load fire first?
"The Page calls the OnLoad event method on the Page, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded."
From this link: http://msdn.microsoft.com/en-us/library/ms178472.aspx
So to answer plainly, the Page_Load event is called before the load event in user controls
If you are talking about an actual inheritance, and not control composition, then all the standard Object Oriented rules apply.
Because these are not separate object, there is only one Load event on your control, and there can be only one Page_Load method, unless you explicitly hide it using the new modifier. So, in essence, there is no difference between the Child page load, and the Parent page load... they are one in the same.
The control's Page_Load should fire first, I believe. Other than the Page_Init event, all other initiation events occur up the control hierarchy.
Edit: I'm wrong up there. The page fires its load event then recursively calls it on child controls, which recursively call it on its child controls, and so on. My bad...
When a page is posted back, which statement runs after page_load is done executing? Without knowing what controls are in the page. This is in VS 2008 debugger.
EDIT:
The question is about knowing which event and for which control comes next.
ASP.NET Page Lifecycle
PreInit
Init
InitComplete
PreLoad
Load
Control Events (e.g. ButtonClick)
LoadComplete
PreRender
SaveStateComplete
Render
Unload
The "next statement" is indeterminate. To put it another way, in the sense of "separation of concerns", it's none of your concern. It's the concern of ASP.NET, but not of individual controls on a page, nor of individual developers debugging a page.
I recommend that you determine what question you really needed answered, and what problem you really needed solved.
Here's an example of "why not": Consider the DataBinding event, which is raised when the Control.DataBind method is called, often from inside of Page_Load. Consider a page that contains a DataGrid control. When Control.DataBind is called, the DataBinding event is raised for the control, and Control.DataBind is then called on each control in Control.Controls, eventually causing DataBinding to be raised for those controls. When it gets to the DataGrid, the control will populate its Controls collection with one row for each row in the input data.
Each of the added controls will need to "catch up". They will go through the PreInit, Init, Load, etc. phases - everything up to DataBind.
There's no way to know ahead of time which controls will be added, so you certainly can't determine which events will be fired, and in which order. In fact, some of the control events will fire or not depending on the previous state of the controls. A SelectedIndexChanged event on a dropdown control in a template column of one of the rows may fire if the dropdown index has changed from the last postback, but not if it has stayed the same!
I have next situation:
I load dynamic controls during on init, and I do correct initialization.
I add dynamic control before postback
I don't add anything later in load
control is loaded and diplayed correctly
I press postback and nothing happens
Why I really don't know.. I tried everything. So control IS properly initialised. __EVENTTARGET shows the same path as the UniqueId of linkbutton that is firing it. All controls in tree have viewstate=true. So, I really don't know what this is not working.
Any idea? I am desperate.. I don't know.. if anyone could suggest me, if not solution, then just things I should check would be very good.
Is this problem just for this page or do you have other pages on the same site with the same problem?
I am assuming that you have the same problem on all pages.
It could be relate do javascript not being allowed. You could try to add the site to local intranet security are, then refresh the page.
Dynamic controls have to be added back to the control tree on each postback for the events to fire.
Dynamically created controls are not part of their container's viewstate, so setting it to TRUE wouldn't have any effect on the situation and are not evaluated until after the on_init call completes anyways.
I would wrap the logic that is populating these dynamic controls in with a conditional check for a postback if(!IsPostBack)
{ //Insert logic here }
If your dynamic controls take input from the user, or need access to their view state, then you would need to move this call to the Page_Load method as this is the point in the page's lifecycle where viewstate is first evaluated.
Is there any kind of event out there that would allow for a preload post back event.
The reason I ask is I have a control that adds sibling controls to it on postback events, however, by the time it has loaded the post back its too late to add the new control to the control collection. Therefore, the controls are never updated correctly.
Thanks!
Try the Init event.
Override CreateChildControls (make sure to call base!). In your postback event handler, make sure you are storing somewhere the list of controls that should be created dynamically, so when CreateChildControls gets invoked very early in the lifecycle on the next go-round, it will recreate the controls built on the last postback.
Here is a quick hack. You can always, query the __EventTarget and or the value of the submit button in init and can load dynamically the control.
But doing so, may not be appropriate as your control hierarchy would change and could cause problems.
As above, dynamic controls have to be added during the page Init event, so that they can be properly handled within the page's Viewstate. You might want to turn the Viewstate off for the page as well, since it can fire errors at you if the controls change.
As has already been stated the proper place to add dynamic controls is in the Init event.
Here's an article with more information.
Dynamic Web Controls, Postbacks, and View State
To get a better understanding of the ASP .NET page life cycle see:
ASP.NET Page Life Cycle Overview
This page explains the event order (and what happens in each one) in a postback, it helped me more than once.
I've just found this link, that can also be of use to you