its really pretty simple.
a control that fires a server click has javascript code that does a
postback (the browser posts all form data) to the server. the exception
is the imagebutton and button which do not require any javascript unless
they are performing validation. the javascript places the name of the
control (and the cmdarg value) in a hidden field before the postback.
the serverside code processes the postback, after page load, it checks
for a control name in the hidden field, it then looks for a control with
that name. if the control implements, IPostBackEventHandler, it calls
RaisePostBackEvent, which is where the control decides what type of
event to raise. Normally the server control will define an event
delegate and call it.
there is a simular approach for postback data handling. the control
implements an inteface (IPostBackDataHandler), is is called with the
postback data, update its self and returns a flag if any data change
events need calling. the page processor will call the handler and the
control will raise the event.
a browser page postback consists of a named value collection of all
browser form fields (<input>, <select> and <textarea>) contained in the
<form> doing the submit. the format is pretty simple:
<fieldname1>=<fieldvalue1>&<fieldname2>=<fieldvalue2>&
the names and values are urlencoded to handle imbedded special characters.
a browser submit button or image button will add itself to the list if
clicked (the image button actually sends a x and a y value via
buttonname_x and buttonname_y). this is how the server tells if one of
them caused the postback.
-- bruce (sqlwork.com)
