Source of a PostBack

Basics of what a PostBack event is:  Most ASP.NET Controls are “Server Controls”. This means that when an action occurs, the Page, which hosts all its controls inside. But, how does the Page class “know” which control was “clicked, changed, or whatever”? Very simply, each control generates plain old client-side Javascript. Since HTTP is stateless and there is no “invisible connection” between the server-side classes and the client-side HTML document in your browser, how can a client-side event be handled on the server side? In ASP.NET, this is done by using hidden form fields. A client-side event, such as an “onclick” or “onchange” event, can be captured by a JavaScript event handler. ASP.Net provides the javascript __doPostBack() function. This records the name of the object that fired the event, as well as any additional event information, places it into the hidden form fields __EVENTTARGET and __EVENTARGUMENT, and then submits the form, initiating our PostBack.
On the server side, any controls that implement either the IPostBackDataHandler or IPostBackEventHandler interfaces (which means that they can process client-side events) will have the appropriate method called to examine the PostBack data and see if they have raised the client-side event. If so, the corresponding server-side event is raised and the event handler method is called. You can create your own custom PostBack by simply calling the ASP.NET “GetPostBackEventReference” method.

 Global.asax.cs codebehind file:

using System;
using System.Collections;
using System.ComponentModel;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;

namespace WhichControlPostedBack{
 public class Global : System.Web.HttpApplication{
  private System.ComponentModel.IContainer components = null;

  public Global(){

public static System.Web.UI.Control GetPostBackControl(System.Web.UI.Page page){
  Control control = null;
  string ctrlname = page.Request.Params["__EVENTTARGET"];
  if (ctrlname != null && ctrlname != String.Empty){
   control = page.FindControl(ctrlname);
  // if __EVENTTARGET is null, the control is a button type and we need to 
  // iterate over the form collection to find it
   string ctrlStr=String.Empty;
   Control c=null;
   foreach (string ctl in page.Request.Form){
    // handle ImageButton controls ...
    if (ctl.EndsWith(".x") || ctl.EndsWith(".y")){
     ctrlStr = ctl.Substring(0,ctl.Length-2);
     c= page.FindControl(ctrlStr);
     c = page.FindControl(ctl);
          if (c is System.Web.UI.WebControls.Button || 
		c is System.Web.UI.WebControls.ImageButton){
     control = c;
  return control;
  private void InitializeComponent(){
   this.components = new System.ComponentModel.Container();

Its a static method – which means you can reference it without a class instance, simply by calling Global.GetPostBackControl(this), with the “this” being a reference to the Page class that you are in. Typically we would do this as follows, in the Page_Load event handler method:

private void Page_Load(object sender, System.EventArgs e){

source: ASP.NET: Which Control Posted Back?


.NET Remoting

Remoting is a system for Microsoft .NET platform that enables interprocess communication in a homogenous environment. With the help of remoting, we can communicate between two processes running on different machines (or different application domains) in a network (but having the same OS). Because remoting uses binary serialization, it is much faster than using web services. However, we cannot use remoting in a heterogeneous environment (say, where an ASP.NET web application is talking to a J2EE application) using a .NET specific API, as other systems, such as J2EE, cannot understand it. Also, the use of remoting when we want to talk to processes outside of the LAN (say, when communicating using WAN or Internet) can be troublesome, as it cannot bypass a firewall until specific access is given to the service. Using web services is preferred in such cases.

source: ASP.NET 3.5 Application Architechture Design