«

My site's login page has a form w/ 2 textboxes and a submit button. If I'm
in either of those textboxes (i.e., either one of the textboxes has focus),
in any given browser, hitting "enter" on my keyboard submits the form.
Server side, I handle the click event of the submit button. This is the
expected behavior, and this is the behavior irrespective of what browser I
use on the login page. However...

I have different page that is an email submittal form. It has just 1
textbox and a submit button. On this page, and only when using IE 6.0,
there is a server-side difference between hitting "enter" as opposed to
physically clicking the submit button on the client. The difference being
that if "enter" is used to submit the form, the page performs a postback
(ispostback = true), but the click event of the button never fires. On the
other hand, if the button is physically clicked on the client, again
ispostback=true but now the click event _does_ fire. This is not the
behavior I was expecting - I expected identical behavior as to my login
form, where the method of submittal on the client is transparent to the
server, which should simply believe that submit button was "clicked".

With other browsers (NN 7.2, FF 1.0, Opera) you can hit "enter" or
physically click and there is no difference server side (the click event
fires either way).

I have gone over the code with a fine toothed comb and cannot find any
relevant difference between my login form and my email form that would cause
this behavior (in fact I was not even aware this behavior was possible). Is
this a known issue of any kind? What exactly should I be looking for here?

I agree that the default behavior is less than intuitive. You can take
control of the situation, however, using client side script.

Here's a couple good articles on the subject:
http://www.allasp.net/enterkey.aspx
http://www.aspnetpro.com/features/20...200406so_f.asp

Or you could just use this free control.
http://www.metabuilders.com/tools/DefaultButtons.aspx

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://Steve.Orr.net


"23s" <> wrote in message
newsumdnXdYHZHl4obfRVn-...
> My site's login page has a form w/ 2 textboxes and a submit button. If
> I'm in either of those textboxes (i.e., either one of the textboxes has
> focus), in any given browser, hitting "enter" on my keyboard submits the
> form. Server side, I handle the click event of the submit button. This is
> the expected behavior, and this is the behavior irrespective of what
> browser I use on the login page. However...
>
> I have different page that is an email submittal form. It has just 1
> textbox and a submit button. On this page, and only when using IE 6.0,
> there is a server-side difference between hitting "enter" as opposed to
> physically clicking the submit button on the client. The difference being
> that if "enter" is used to submit the form, the page performs a postback
> (ispostback = true), but the click event of the button never fires. On
> the other hand, if the button is physically clicked on the client, again
> ispostback=true but now the click event _does_ fire. This is not the
> behavior I was expecting - I expected identical behavior as to my login
> form, where the method of submittal on the client is transparent to the
> server, which should simply believe that submit button was "clicked".
>
> With other browsers (NN 7.2, FF 1.0, Opera) you can hit "enter" or
> physically click and there is no difference server side (the click event
> fires either way).
>
> I have gone over the code with a fine toothed comb and cannot find any
> relevant difference between my login form and my email form that would
> cause this behavior (in fact I was not even aware this behavior was
> possible). Is this a known issue of any kind? What exactly should I be
> looking for here?
>

Thank you, this is certainly it.

"Steve C. Orr [MVP, MCSD]" <> wrote in message
news:...
>I agree that the default behavior is less than intuitive. You can take
>control of the situation, however, using client side script.
>
> Here's a couple good articles on the subject:
> http://www.allasp.net/enterkey.aspx
> http://www.aspnetpro.com/features/20...200406so_f.asp
>
> Or you could just use this free control.
> http://www.metabuilders.com/tools/DefaultButtons.aspx
>
> --
> I hope this helps,
> Steve C. Orr, MCSD, MVP
> http://Steve.Orr.net
>
>
> "23s" <> wrote in message
> newsumdnXdYHZHl4obfRVn-...
>> My site's login page has a form w/ 2 textboxes and a submit button. If
>> I'm in either of those textboxes (i.e., either one of the textboxes has
>> focus), in any given browser, hitting "enter" on my keyboard submits the
>> form. Server side, I handle the click event of the submit button. This
>> is the expected behavior, and this is the behavior irrespective of what
>> browser I use on the login page. However...
>>
>> I have different page that is an email submittal form. It has just 1
>> textbox and a submit button. On this page, and only when using IE 6.0,
>> there is a server-side difference between hitting "enter" as opposed to
>> physically clicking the submit button on the client. The difference
>> being that if "enter" is used to submit the form, the page performs a
>> postback (ispostback = true), but the click event of the button never
>> fires. On the other hand, if the button is physically clicked on the
>> client, again ispostback=true but now the click event _does_ fire. This
>> is not the behavior I was expecting - I expected identical behavior as to
>> my login form, where the method of submittal on the client is transparent
>> to the server, which should simply believe that submit button was
>> "clicked".
>>
>> With other browsers (NN 7.2, FF 1.0, Opera) you can hit "enter" or
>> physically click and there is no difference server side (the click event
>> fires either way).
>>
>> I have gone over the code with a fine toothed comb and cannot find any
>> relevant difference between my login form and my email form that would
>> cause this behavior (in fact I was not even aware this behavior was
>> possible). Is this a known issue of any kind? What exactly should I be
>> looking for here?
>>
>
>