the communication betweoen the client and server are html form fields
(input,select, and textarea). when a postback happens the form fields
are sent to the server as name/value pairs.
when you write a server control your control responds to two events (not
real events they are interface methods rather than delegates) generated
by the frame work.
1) LoadPostData - your control called and passed all the form postback
values, and your data key (rendered control name).
you can store you original value in viewstate, and compare the postback
value to it. if different you can raise some sort of OnChange event
2) RaisePostBackEv ent - you control will render some client script to
raise this event by calling __dopostback with the control name and one
option string arg. the name and arg are stored in hidden fields and form
postback is done.
server side the framework will see this control name in the postback
data, and call this RaisePostBackEv ent. your control then raises
whatever event(s) (say onclick) it wants.
see its all very simple.
-- bruce (sqlwork.com)
John Dalberg wrote:
What causes a server event to fire when something happens on the client?
Say a user changed the gridview's page index, the server side
PageIndexChange d event is fires.
What makes PageIndexChange d fires? Is it a field in the viewstate? Is it a
value in the forms collections? I am trying to understand the mechanism of
communication between the browser and the server.
John Dalberg
