Hi,

It seems that a (the first?) webforms button control on a page is set as the equivalent of the WinForms AcceptButton property. That is, hitting ENTER on a page which contains, say, a few text boxes, and a web button will by default cause the page to postback, regardless of anything else that may going on in the page.

It there any way to disable this, or alternatively assign this behavior to a specific button on the page? I do not want the page to submit when the ENTER key is pressed until I am good and ready for it; it's OK for the button to submit when it is explicitly clicked, just not when ENTER is hit...

Thanks for any help you can give.

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

__________________
-- Jeff

Can you add validation to the page and in the button1_click event check to see if the Page IsValid?

There are already a bunch of validation controls on the page, and they work well enough - nothing "bad" gets through. The users, though, are using the page to enter a bunch of text data and apparently are in the the habit of hitting the ENTER key prematurely. This means the validations fire before the users are really finished, and it "upsets their rhythm" (honest - that's what their manager said).

What I'd really like is to "swallow" the ENTER key so that no button did a submit on ENTER - this would solve this issue. It's perfectly OK for the users to click on the "I'm done" button prematurely - then they get whatever validations they should get. It's just the ENTER key behavior I'm trying to modify.

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

For all text boxes that need to swallow the enter, add a js call in the onKeyPress attribute. Trap the keycode for enter and null out the keycode.

function swallowEnter(){
    if(event.keyCode==13){
        event.keyCode = null;
        return;
    }
}

Here's a working sample:
http://www.geekdork.com/samples/swallowEnter.aspx

Or cause enter to be equivalent to tab:

function swallowEnter(){
    if(event.keyCode==13){
        event.keyCode = 9;
    }
}

HTH,

Snib

<><

Thanks guys; that'll do the trick, although I had hoped for a way to modify the behavior of the button, rather than each of the several other widgets on the form.

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

Unfortunately, modifying the button behavior won't help because the problem is in the textbox behavior.

You could create your own textbox: the NoEnterTextBox. I think it would work something like this:

Public Class NoEnterTextBox : Inherits System.Web.UI.WebControls.TextBox
    Private Sub NoEnterTextBox_PreRender(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.PreRender
        Me.Page.RegisterClientScriptBlock("NoEnterTextBoxJ S", "<script language=""JavaScript"">function swallowEnter(){if(event.keyCode==13){event.keyCode = null; return;}}</script>")
        Me.Attributes.Item("onKeyPress") = "swallowEnter();"
    End Sub
End Class

You could either do this as a custom control, or as a user control.

Alternatively, you could add in something that goes thru all the controls on the page, looks for "TextBox" controls and modifies them with the addition of the onKeyPress call. This might be easiest because it would handle all textboxes on the whole page. Just remember to look recursively thru the controls collection.

Not trying to be combative here, but how is this a behavior of a textbox? It seems to me that the issue is that ENTER typed anywhere on a page containing a submit button results in the page being submitted, notwithstanding any controls that have their autopostback property set. That behavior seems to be related to the button and not the textbox. If I have a form with some textboxes, and no textbox has autopostback set, then hitting ENTER, no matter where the cursor is, will cause a page submit, and that's the behavior I'm trying to modify.

Of course, what do I know - especially when it comes to this ASP.NET stuff :D ?

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

Alas, this doesn't seem to work. The ENTER is swallowed, but nothing seems to happen with the TAB - the cursor stays put...

Jeff Mason
Custom Apps, Inc.
www.custom-apps.com

I just did a test with that sample I created. I removed the button and the form doesn't submit. So it seems to be a form behavior influenced by the existance of a submit button.