Online Book Reader

Home Category

Programming Microsoft ASP.NET 4 - Dino Esposito [452]

By Root 5274 0
is thrown is when the Update method is called during or after the page’s rendering stage.

So when should you use the Update method in your pages?

You resort to the method if you have some server logic to determine whether an UpdatePanel control should be updated as the side effect of an asynchronous postback—whether it is one that originated from another UpdatePanel in the page or a control registered as an asynchronous postback control.

Using Triggers


As mentioned, you can associate an UpdatePanel control with a list of server-side events. Whenever a registered event is triggered over a postback, the panel is updated. Triggers can be defined either declaratively or programmatically. You add an event trigger declaratively using the section of the UpdatePanel control:

...

ControlID="DropDownList1"

EventName="SelectedIndexChanged" />

You need to specify two pieces of information for each trigger: the ID of the control to monitor, and the name of the event to catch. Note that the AsyncPostBackTrigger component can catch only server-side events. Both ControlID and EventName are string properties. For example, the panel described in the previous code snippet is refreshed when any of the controls in the page posts back (that is, its UpdateMode property defaults to Always) or when the selection changes on a drop-down list control named DropDownList1. (Obviously, the DropDownList1 control must have the AutoPostBack property set to true.)

Note

You can also add triggers programmatically by using the Triggers collection of the UpdatePanel control. The collection accepts instances of the AsyncPostBackTrigger class.

Full Postbacks from Inside Updatable Panels


By default, all child controls of an UpdatePanel that post back operate as implicit asynchronous postback triggers. You can prevent all of them from triggering a panel update by setting ChildrenAsTriggers to false. Note that when ChildrenAsTriggers is false, postbacks coming from child controls are processed as asynchronous postbacks and they modify the state of involved server controls, but they don’t update the user interface of the panel.

There might be situations in which you need to perform full, regular postbacks from inside an UpdatePanel control in response to a control event. In this case, you use the PostBackTrigger component, as shown here:

...

EventName="SelectedIndexChanged" />

The preceding panel features both synchronous and asynchronous postback triggers. The panel is updated when the user changes the selection on the drop-down list; the whole host page is refreshed when the user clicks the button.

A PostBackTrigger component causes referenced controls inside an UpdatePanel control to perform regular postbacks. These triggers must be child elements of the affected UpdatePanel.

The PostBackTrigger object doesn’t support the EventName property. If a control with that name is causing the form submission, the ASP.NET AJAX client script simply lets the request go as usual. The ASP.NET runtime then figures out which server postback event has to be raised for the postback control by looking at its implementation of IPostBackEventHandler.

Note

When should you use a PostBackTrigger component to fire a full postback from inside an updatable panel? If you need, say, a button to refresh a given panel, why not list the Click event of the button as an asynchronous trigger and leave the button outside the panel?

Especially when complex and templated controls are involved, it might not be easy to separate blocks of user interface in distinct panels and single controls. So the easiest, and often the only, solution is wrapping a whole block of user

Return Main Page Previous Page Next Page

®Online Book Reader