I have two user controls on a page - UC1,UC2. Each usercontrol have a asp:button. Now if I click the any of the buttons the page post back. Now if I click the button of UC1 then the following happen.
Viewstate load for two user controls.
Page load called for two user controls.
The event handler of UC1 button is fired.
Now if user click on the UC1 button, I do not want to load the view state of UC2 user controls at server because the viewstate of UC2 is large.
The execution of UC1 is not dependent of UC2.
Please suggest how can I achive this.
Thanks!
What it sounds like your asking for is the ability to do partial postbacks. That is postbacks that only affect a portion of the page. There are a number of ways to accomplish this such as using the Microsoft provided AJAX controls (http://www.asp.net/ajax) or rolling your own with JQuery and web methods (this method however is stateless and should be expected as such). Specifically you will want to look at UpdatePanels and PostBack Triggers.
Hope this helps.
Related
I am trying to take advantage of the page lifecycle in Asp.NET so that I don't bind to my datasources more than I actually need to.
This has led to the following problem. I have an ObjectDataSource, GridView, and a button on my page. The button adds a record to the database, which should be picked up by the data source and presented on the Grid. The problem is that the item is not showing up on the gridview until I refresh the page.
I can solve the problem by calling GridView.DataBind() in my button's event handler, but this goes against what I understand about the .NET Page Lifecycle.
Based on this article, the lifecycle should be as follows:
In addition the article states that the Databinding event is "Raised after the control's PreRender event, which occurs after the page's PreRender event."
So, my button click event should fire first, during the Event Handling phase. It should add the record the database.
Next PreRender should be called on the controls.
Finally DataBind should be called on the controls, and the Grid should update to capture the new record.
Yet this doesn't seem to happen. What am I not understanding?
I think the issue is that your viewstate is not enabled on your GridView. This is what I experienced, but then I also had to call DataBind() on the GridView from the page PreRender event if the request was a postback to get the data updated in the GridView on postback.
Edit:
It would help to understand the issue and context better if you could post the source code of your page (aspx + codebehind). How and where do you connect your GridView to your datasource? Statically in markup or dynamically? Do you make any calls to page.DataBind()? ... These things may influence the behaviour of the GridView.
I have a ListView control and in the LayoutTemplate I have Previous and Next paging buttons. On clicking the buttons, a PageButton_Click event handler in the code behind file is called to do the paging. It works fine, but if I switch off the ViewState of the ListView, clicking the buttons would not be able to call the event handler in the code behind. What is happening here?
all the server controls events are stored in viewstate. if you want to off the viewstate then not any server control work. if you want to off the viewstate then implemented the logic using javascript or jquery.
I've seen code to handle MasterPage events in the content Page, but if I'm loading a UserControl dynamically into the Page, can I handle the event in the UserControl instead?
Basically I have a button on the MasterPage, when it's clicked I need to make the UserControl do something, such as display text or change a value in a form.
Failing that, is it possible to make an event from one dynamically loaded UserControl fire in another on the same page? I could then replace the button in the MasterPage with one in another UserControl
Thanks all.
This is very similar to this stackoverflow question.
The answer to that question should also apply to yours: your Page knows its master and knows its child controls. It can wire-up a handler on the child control to an event on the master page, so the child control can perform necessary functionality when the even occurs on the master page.
I was going through an article on event bubbling in asp.net and came to know that although it is possible to subscribe to the click event of a user control's button from the containing page, "doing so would break some of the object oriented rules of encapsulation". A better idea is to publish an event in the user control to allow any interested parties to handle the event.
My question is that exactly how does a direct subscription to the button's click event from a containing page would break the object oriented rules of encapsulation?
Apologies if its a dumb question. :|
Thanks!
The Button is supposed to be encapsulated by the UserControl.
If the Page binds directly to events on the button, then the page is now dependent on the inner workings of the UserControl.
The Page should be consuming the UserControl, not the UserControl's button. If the author of the UserControl later wants to remove the button and use some fancy new method of firing its "Submit" event, your page could be broken because the button may no longer exist.
For that matter, if the owner of the UserControl decides in v1.1 to rename the button from btnSubmit to SubmissionButton, it could break your page, as well.
Better to consume the UserControl and let it be concerned with its own inner workings.
The idea is that the button of the control is an implementation detail of the UI of the control. If you republish the click event you could reimplement that button as an ImageButton, LinkButton, etc.
I think it's OK to attach an event handler at the page level to the button if the button is a permanent fixture of the UI. It saves a lot of event code, especially with a lot of buttons.
In my web application I load user controls in the page_loadComplete event. This works fine, however when a button is clicked in a user control, the click event is never fired. Does this has something to do with the page lifecycle? That button click (UI) events occur before the LoadComplete event?
You need to make sure the click event of the button is once again subscribed to, before event handlers fire. LoadComplete happens after control events. For a reference, the ASP.NET Page Life Cycle Overview gives a pretty nice summary.
Snippet:
...
Load
Control events
LoadComplete
PreRender
...
You also need to make sure that the controls that you dynamically load all end up in the same place, so viewstate and controlstate can be reapplied to the same hierarchy as before postback.
Basically, you need to load all dynamic controls on each postback.
Here's someone with the same problem, and solutions to some of them: ASP.NET dynamic controls
Actually what is happening to your situation is, when you click on the button, before event raising, LoadCoplete event fire first in the page lifecycle and same control is again created and here is your event is lost.
Event Handling in ASP.NET page happens after Validation and before Rendering phase. And Validation phase happens after Load.
LoadComplete happens after Control events and before RreRender event.