By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,742 Members | 1,570 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,742 IT Pros & Developers. It's quick & easy.

How to do a post back when user press enter.

P: n/a
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
Nov 19 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Either you use javascript functionality to do document.myform.submit() or
you let the user press enter twice,
so that he gets onto submit-button on pressing enter in input-field.

Am Sun, 29 May 2005 14:56:14 +0200 schrieb <"guoqi zheng"<no@sorry.com>>:
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


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Nov 19 '05 #2

P: n/a
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@sorry.com> wrote in message
news:72******************************@ureader.com. ..
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

Nov 19 '05 #3

P: n/a
Guoqi,

"Enter" key functionality of a regular html form is achieved by using an
<input type=submit> control. Nothing stops you from using the same control
in an aspx form:

<input type="submit" value="Submit">

If you want it to be a server control or/and to generate a server-side
onclick event, add attributes runat=server and OnServerClick="MyHandler"

Eliyahu

"guoqi zheng" <no@sorry.com> wrote in message
news:72******************************@ureader.com. ..
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

Nov 19 '05 #4

P: n/a
PB
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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@sorry.com> wrote in message
news:72******************************@ureader.com. ..
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


Nov 19 '05 #5

P: n/a
When I first see this long answer, I was thinking that another school pro. I
am not going to read it.

But after I read it... Thanks for a lot for the detail explaination.

I know what to do now.

Thanks.

regards,

Guoqi Zheng
http://www.ureader.com
Nov 19 '05 #6

P: n/a
You're very welcome, Guoqi, and thank YOU for taking the time to read it!

--

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"guoqi zheng" <no@sorry.com> wrote in message
news:c0******************************@ureader.com. ..
When I first see this long answer, I was thinking that another school pro.
I
am not going to read it.

But after I read it... Thanks for a lot for the detail explaination.

I know what to do now.

Thanks.

regards,

Guoqi Zheng
http://www.ureader.com

Nov 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.