避免 Windows“叮”声当使用 OnKeyUp 在 TextBox 中按下 Enter 时

发布于 2024-11-19 17:18:58 字数 138 浏览 3 评论 0原文

如果用户通过 KeyUp 事件在 Windows 窗体文本框中按下 Enter 键,Windows 会发出蜂鸣声或叮声。我无法确定为什么会发生这种情况以及如何避免这种情况。

任何帮助将不胜感激。

If a user hits enter in a windows forms textbox with a KeyUp Event, windows sounds a beep or ding. I could not determine why this happens and how I could avoid this.

Any help would be appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

∞琼窗梦回ˉ 2024-11-26 17:18:58

消除声音的实际解决方案:

private void TextBox_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyCode == Keys.Enter)
    {
        e.SuppressKeyPress = true;
    }
}

Actual solution for getting rid of the sound:

private void TextBox_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyCode == Keys.Enter)
    {
        e.SuppressKeyPress = true;
    }
}
仅此而已 2024-11-26 17:18:58

我想这是由以下组合引起的:

  • MultiLine = false
  • 表单上没有默认按钮

,因为单行文本框将 Enter 键转发到默认按钮。当找不到默认按钮时会生成叮当声。

I imagine this is caused by a combination of:

  • MultiLine = false
  • No default button on the form

because single-line textboxes forward the enter key to the default button. The ding is generated when a default button can't be found.

疏忽 2024-11-26 17:18:58

这是实际的答案:

    Private Sub myTextBox_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles myTextBox.KeyPress
    If Asc(e.KeyChar) = 13 Then
        e.Handled = True
    End If
End Sub

这会吃掉按键,从而防止叮当声。

Here is the actual answer:

    Private Sub myTextBox_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles myTextBox.KeyPress
    If Asc(e.KeyChar) = 13 Then
        e.Handled = True
    End If
End Sub

This eats the key press, which prevents the ding.

尹雨沫 2024-11-26 17:18:58

经过几个小时的寻找解决方案后,我得到了一个解决方法,但并不是这个问题的真正解决方案。现在我改用KeyDown

private void tbSearch_KeyDown( object sender, KeyEventArgs e )
{
    if ( e.KeyCode == Keys.Enter )
    {
         e.Handled = true;
         // Call Button event
         //btnSearch_Click( sender, EventArgs.Empty );
         // cleaner code. Thanks to Hans.
         btnSearch.PerformClick();
    }
}

并向所有开发人员提出一个有用的建议:不要在静音的情况下测试您的应用程序。 ;-)

After some hours digging for a solution, I just got a workaround, but not a real solution for this problem. Now I'm using KeyDown instead.

private void tbSearch_KeyDown( object sender, KeyEventArgs e )
{
    if ( e.KeyCode == Keys.Enter )
    {
         e.Handled = true;
         // Call Button event
         //btnSearch_Click( sender, EventArgs.Empty );
         // cleaner code. Thanks to Hans.
         btnSearch.PerformClick();
    }
}

And a useful suggestion to all developers: Don't test your applications whit mute sound. ;-)

时光倒影 2024-11-26 17:18:58

上述解决方案都不适合我......但这是我的简单解决方案!
仅当您的应用程序中不再需要“接受”按钮时,它才起作用。

private void txtPassword_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyCode == Keys.Enter) { cmdLogin.PerformClick(); }
}

private void txtPassword_Enter(object sender, EventArgs e)
{
    this.Acceptbutton = this.cmdLogin;
}

private void txtPassword_Leave(object sender, EventArgs e)
{
    this.Acceptbutton = Null;
}

这样,当按下“Enter”键时,您将不会听到焦点所在的特定文本框上的 ping 声!

None of above solutions did the job for me ... but here's my simple solution!
It works only when you have no further need for an Acceptbutton in your App.

private void txtPassword_KeyDown(object sender, KeyEventArgs e)
{
    if (e.KeyCode == Keys.Enter) { cmdLogin.PerformClick(); }
}

private void txtPassword_Enter(object sender, EventArgs e)
{
    this.Acceptbutton = this.cmdLogin;
}

private void txtPassword_Leave(object sender, EventArgs e)
{
    this.Acceptbutton = Null;
}

In this way you won't hear the ping on the specific textbox with the focus when 'Enter' is pressed!

幸福不弃 2024-11-26 17:18:58

当用户从单行文本框中按 Enter 键时,当我从自定义控件调用 myDialog.ShowDialog() 时,会发生此问题的一个版本。

(他们将产品编号放入文本框中,按 Enter 键,然后弹出对话框,让他们从可用尺寸中进行选择。但是,如果每次弹出对话框时都播放铃声,那就太烦人了。)

我将按键事件捕获在文本框,并设置 e.Handled 和 e.SupressKeypress,但这并没有解决问题。然后我注意到,如果我注释掉对 myDialog.ShowDialog() 的调用,那么我就听不到声音,这很奇怪。在这种情况下,e.Handled 和 e.SupressKeypress 确实阻止了响铃。

我认为该事件可能以某种方式传递到对话框,因此我在表单级别以及表单中需要击键的每个元素上捕获了 keydown 事件,并在每个元素中设置了 e.Handled 和 e.SuppressKeypress那些,但这并没有解决问题。

我尝试在表单上放置一个提交按钮并将表单的 AcceptButton 属性设置为该按钮,但这也没有帮助。

我尝试在调用 myDialog.ShowDialog() 之前调用 Application.DoEvents() ,但这并没有解决问题。

我注意到,即使对 myDialog.ShowDialog() 的调用被注释掉,调用 Application.DoEvents() 也会导致铃声响起!就好像调用 DoEvents 正在处理当前事件,而不注意 e.Handled 和 e.SupressKeypress 限定符。

所以..我想如果我在预选赛进行时让当前的赛事进行,然后然后提出我的对话会怎么样?

因此,我将 myDialog.ShowDialog() 放入 BeginInvoke 部分(因为我的印象是调用将一条消息添加到主消息队列中,导致在处理该消息时调用该方法):

        BeginInvoke((MethodInvoker)delegate {
            SelectProduct(); // <-- pops the size selection dialog
        });

不管你信不信,这修复了它向上 - 没有铃声。

(当后台线程调用回调时,当我需要更新视图时,我通常使用调用,因为 WinForms 视图不允许从主线程以外的线程更新自身。)

所以我猜测自定义控件,单行文本框所在的位置是需要接受按钮的位置 - 但自定义控件没有 AcceptButton 属性。

WinForms 编程似乎有点玄妙。我想就像所有其他类型的编程一样。

I had a version of this problem that would happen when I called myDialog.ShowDialog() from a custom control when the user hit enter from a single line text box.

(They put a product number into a text box, hit enter, and the dialog pops and lets them select from the available sizes. But it's supper annoying if a bell sound plays every time the dialog pops.)

I trapped the key down event in the text box, and set e.Handled and e.SupressKeypress, but that didn't solve the problem. Then I noticed that if I commented out the call to myDialog.ShowDialog(), then I didn't get the sound, as weird as that is. In that case, e.Handled and e.SupressKeypress did prevent the bell.

I thought maybe the event was somehow getting passed on to the dialog, so I trapped the keydown event at the form level and on every element of the form that takes keystrokes at all, and set e.Handled and e.SuppressKeypress in every one of those, but that didn't fix it.

I tried putting a submit button on the form and setting the AcceptButton property of the form to that button, but that didn't help either.

I tried calling Application.DoEvents() before calling myDialog.ShowDialog(), but that didn't fix it.

I noticed that calling Application.DoEvents() caused the bell to play even when the call to myDialog.ShowDialog() was commented out! As if calling DoEvents was processing the current event without paying attention to the e.Handled and e.SupressKeypress qualifiers.

So.. I thought what if I let the current event play out while the qualifiers are in play, and then raise my dialog after that?

So I put myDialog.ShowDialog() into a BeginInvoke section (since my impression is that an invoke adds a message into the main message queue that causes the method to get called when that message is processed):

        BeginInvoke((MethodInvoker)delegate {
            SelectProduct(); // <-- pops the size selection dialog
        });

Believe it or not, that fixed it up - no bell.

(I commonly use invokes when I need to update the view when a background thread calls a callback, since WinForms views don't allow themselves to be updated from a thread other than the main thread.)

So I'm guessing the custom control, where the single line text box is, is where an accept button is needed - but a custom control has no AcceptButton property.

WinForms programming seems to be a bit of a black art. Just like every other kind of programming, I guess.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文