Si un utilisateur frappe dans une zone de texte Windows Forms avec un événement KeyUp , Windows sonne un bip ou ding . Je ne pouvais pas déterminer pourquoi cela se produit et comment je pourrais éviter cela.
Toute aide serait appréciée.
6 Réponses :
Après quelques heures de creuser une solution, je viens de recevoir une solution de contournement, mais pas une solution réelle pour ce problème. Maintenant, j'utilise Keydown fort> à la place. 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();
}
}
Remplacez le processusCMDKey () à la place afin que cela fonctionne n'importe quel contrôle a la mise au point. Renvoie true lorsque vous reconnaissez Keys.enter pour éviter la ding. Vous pouvez utiliser Button.PerformClick () BTW.
Bouton.PerformClick () est un bon point. Je ne le savais pas. Mais Processcmdkey compliquerait mon travail, car j'ai beaucoup de boutons et de boîtes de texte. J'aurais toujours besoin de vérifier qui était l'expéditeur. J'utilise la méthode processdialogkey pour certains événements clés globaux tels que F3 pour Save, F1 pour l'aide ...
J'imagine que cela est causé par une combinaison de:
multiline = false
- Pas de bouton par défaut sur le formulaire
Parce que des boîtes de texte mono-ligne transmettent la touche Entrée du bouton par défaut. La DIG est générée lorsqu'un bouton par défaut est introuvable.
Maintenant, je comprends la ding. Et j'ai vérifié ça. Avec MULTILINE = FALSE: Si je définis ce bouton dans les formulaires Accepterbutton, il est activé immédiatement. Donc, il n'y a pas de ding, mais j'ai beaucoup d'autres boutons et ce n'est pas mon bouton d'acceptation. Si je définis Multiline = vrai, la Ding est parti aussi. C'est ce que j'ai préféré, en plus wordwrap = false. Merci pour l'aide.
Voici la réponse réelle:
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
solution réelle pour vous débarrasser du son:
Aucune des solutions ci-dessus n'a fait le travail pour moi ... mais voici ma solution simple!
Cela ne fonctionne que lorsque vous n'avez plus besoin d'un accepteur d'acceptation dans votre application.
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;
}
J'ai eu une version de ce problème qui se produirait lorsque j'ai appelé mydialog.showdialog () à partir d'un contrôle personnalisé lorsque l'utilisateur a appuyé sur une zone de texte unique.
(ils mettent un numéro de produit dans une zone de texte, appuyez sur Entrée et la boîte de dialogue apparaît et leur permet de choisir parmi les tailles disponibles. Mais c'est le souper gênant si un son de cloche joue à chaque fois que la boîte de dialogue apparaît.) P>
J'ai emprisonné la touche Down Event dans la zone de texte et définissez E.Handled et E.SuPressKetPress, mais cela n'a pas résolu le problème. Ensuite, j'ai remarqué que si j'ai commenté l'appel à mydialog.showdialog (), alors je n'ai pas eu le son, aussi bizarre que c'était. Dans ce cas, E.Hendled et E.SuPressKetPress ont empêché la cloche. P>
Je pensais que l'événement était peut-être passé à être transmis à la boîte de dialogue, donc j'ai piégé l'événement de la clé au niveau de la forme et sur chaque Elément du formulaire qui prend des frappes de frappe du tout et définit E.Handled et E.SuppressKyPress dans chacun de ceux-ci, mais cela ne l'a pas réparais. P>
J'ai essayé de mettre un bouton de soumission sur le formulaire et Réglage de la propriété Accepterbutton du formulaire sur ce bouton, mais cela n'a pas aidé non plus. P>
J'ai essayé d'appeler l'application.Deevents () avant d'appeler myDialog.showdialog (), mais cela n'a pas réussi. P>
J'ai remarqué que l'application appelante.Deevents () a causé la cloche de jouer même lorsque l'appel à MyDialog.Showdialog () a été commenté! Comme si appeler les doigts traitait l'événement en cours sans attirer l'attention sur les qualificateurs E.Hhandled et E.SuPressKyPress. P>
Alors .. Je pensais si je laisse l'événement actuel jouer pendant que les qualificatifs sont en jeu. , et puis em> montrez ma boîte de dialogue après cela? p> donc je mets mydialog.showdialog () dans une section BeginInvoke (car mon impression est qu'une invoquée ajoute un message dans le message principal La file d'attente qui provoque la méthode d'être appelée lorsque ce message est traité): p> BeginInvoke((MethodInvoker)delegate {
SelectProduct(); // <-- pops the size selection dialog
});