Hi Guoqi,
You need to understand the ASP.Net object model more clearly. Let me see if
I can explain it to you so that you understand a bit better.
First, remember that ASP.Net lives and works in the same enviornment as any
web site does. It is hosted on a web server, with pages that are requested
by a client browser, served up via HTTP. The pages are generated by an ISAPI
(Internet Server Application Programming Interface) application on the
server, which is ASP.Net, but they are still HTML documents when they reach
the client browser, which is designed to read and interpret HTML.
So, the rules of HTML still apply on the client, and the page behaves just
as any other HTML page would behave in a browser. The transport protocol is
still HTTP, so the same rules and environment of HTTP still apply. This
means that, as HTTP is stateless, each Request/Response happens "in a
vacuum" so to speak. That is, the client fires a request to the web server,
and the web server fires (and forgets) a Response to the client. An HTML
page is an isolated instance of a browser window, with no memory of anything
previous, other than the built-in browser memory for such things as the
Referer (last page URL requested) and the history (a list of URLs visited).
ASP.Net is a server-side object-oriented event-driven programming model.
Now, as HTTP is stateless, how are events going to be processed on the
server, which doesn't even remember what page URL the client last Requested,
or anything about that page? In a Windows application, which has persistent
memory, an event is fired by an application, and the event handler IN that
application responds via the application, making changes to its process and
UI, via the event handler. So, the first obstacle to overcome is how to have
an event occur in a client HTML page, be transmitted back to the server, and
have the server respond to the event while "updating" the very same HTML
page (which is actually an entirely new instance of that page)?
The answer is, the page is a form (a WebForm) which posts to its own URL (as
diffeentiated from "itself" which is of course, impossible, since it is on
the client, not the server), resulting in a new instance of the same page in
the browser. The PostBack data is simply HTML form data containing
information about the current state of the page on the client (in the
browser). Thus we have the ASP.Net WebForm PostBack event model.
By now you should see that, as the page on the client is simply an HTML
form, pressing the ENTER key would indeed submit the page back to its own
URL. So, you're first assumption ("in ASP.NET web form, a form will only be
submitted (post back) when a special button is clicked") is wrong. In fact,
we get questions almost daily about how to PREVENT an ASP.Net page from
posting back when the ENTER key is pressed.
What you may be mixing up is in regards to the event model I described. In
order for the server to handle an event from a specific Control (form
element on the client HTML document), the server must know which Control
(form element on the client HTML document) was in fact clicked (or changed).
This brings us to the second element of the ASP.Net event model, which is
how to tell which Control caused the event.
Again, we're talking about a plain vanilla HTML document on the client side.
So, how does an HTML form tell the server anything? It does so via the form
fields whose values are posted back to the form handler. Now, how would an
HTML form send information about a client-side event to the server in its
form values collection? First, you would need a client-side event handler.
This is available through JavaScript (an "onclick" event handler in
JavaScript, for example, or an "onchange" event handler for something like a
drop-down list box). Second, you would need a hidden form field that the
JavaScript can put a value into. In fact, ASP.Net automatically generates
such JavaScript and the appropriate form fields when you insert a Control
into an ASP.Net page.
So, the user clicks a button. The "onclick" JavaScript event-handler for
that button is fired, which then puts the ID of the button into one hidden
form field, and the value of the button into another hidden form field. The
value isn't important with a button, but, for a textbox, for example, the
value is important. The form is posted back to the same Page class on the
server (via its URL being the same), which then reads the form field values,
and rebuilds the page according to your custom Event Handler methods in that
Page class. Then it returns a modified version of the same HTML document to
the client, which starts the whole process all over again.
There is a lot more to it than that, but hopefully the appetizer will whet
your appetite.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.