Re: How to do a post back when user press enter.

Kevin,

I just wanted to take a second to thank you for your great explanations;
not only to the OP here, but your responses in general.

You don't have to offer these great insights and "birds eye" views of
ASP.NET, but you do, and it has been incredibly helpful. Your answers
prevent many other questions from having to be asked... definitely "MVP
stuff."

-PB


"Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23ZIZUJFZFHA.2520@xxxxxxxxxxxxxxxxxxxxxxx
> 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.
>
> "guoqi zheng" <no@xxxxxxxxx> wrote in message
> news:72b3ec6d37ea407b8a15107ebe2d3994@xxxxxxxxxxxxxx
>> In a regular html form, when user press "enter" key, the form will be
>> submitted.
>>
>> However, in ASP.NET web form, a form will only be submitted (post back)
>> when
>> a special button is clicked. Many user get used to click "enter" key to
>> submit a form. How can I use "enter" key to submit/postback in ASP.NET.
>>
>> Thank,
>>
>> Guoqi Zheng
>> http://www.ureader.com
>
>


.