I have to process enter (among other keys) on win form without it producing error sound, but only if the currently active control didn't process it already.
So, when enter is pressed while in a TextBox or DateTimePicker, i want to process it with a form (without error sound), but if it is pressed, for example, in DataGridView i want it to be handled the way DataGridView does by default.
OnKeyUp solves my problem with handling only unhandled keystrokes (e.Handled) and ProcessCmdKey (this) solves sound problem, but neither solves both.
Any suggestions?
Kudos for the very interesting question. Unfortunately, I can't seem to find a global event handler for all key presses other than overriding ProcessCmdKey on the main form per this article. Only issue with this method is that the arguments passed into the event handler delegate don't define what control is creating the event :(
So, my only thought is that you need to assign your event handler to every single control in the application. I've written some code that should help show you how to do this. I'm not sure what the adverse effects may be of assigning a KeyPress event handler to every control on your page though, but it's the only feasible solution I see.
Code:
private void Form1_Load(object sender, EventArgs e)
{
AssignHandler(this);
}
protected void HandleKeyPress(object sender, KeyPressEventArgs e)
{
if (e.KeyChar == (char)Keys.Enter && (sender != this.textBoxToIgnore || sender ! this.gridViewToIgnore))
{
PlaySound(); // your error sound function
e.Handled = true;
}
}
public void AssignHandler(Control c)
{
c.KeyPress += new KeyPressEventHandler(HandleKeyPress);
foreach (Control child in c.Controls)
{
AssignHandler(child);
}
}
Related
Is there a method which initiates on focus change and can be overridden?
My goal is for the program to fetch closest data automatically from database to input fields whenever user changes his focus/presses enter or tab when on corresponding field. I'm still looking for a way to do this when user selects an item by mouse.
I'm aware that this could be implemented on mouse click but I refuse to believe that there is not a general method for focus change.
What about something like this:
foreach(Control ctrl in this.Controls)
{
ctrl.Enter += new EventHandler(Focus_Changed); // Your method to fire
}
Iterate through all controls and add a enter-event. Bind this handler to your method.
Edit:
Just in case you are wondering why "Enter" and not "LostFocus" or something like that: From my knowledge not every control got focus-events. As I've seen so far "Enter" is presented for all. Maybe there are exceptions. Should be checked out...
You could use Control.Enter event and Control.Leave event for that purpose.
See on MSDN Control.Enter and
Control.Leave.
textBox1.Enter += textBox1_Enter;
textBox1.Leave += textBox1_Leave;
private void textBox1_Enter(object sender, System.EventArgs e)
{
// the control got focus
}
private void textBox1_Leave(object sender, System.EventArgs e)
{
// the control lost focus
}
I'm writing a Hangman program in C# and when I press a keyboard button I want the button on the form to be clicked. Where should I write this? In form1.load()?
No, you should select the Form on which you want the event to be triggered, then go to the properties pane, select the event tab and go down to KeyPress event, double click it and add some code.
Normaly something like this would do what you want, just google the KeyChar value to determine the keyPress you want to control, you can add more if statements:
private void Form1_KeyPress(object sender, KeyPressEventArgs e)
{
if (e.KeyChar == (char)13)
{
Button1.PerformClick();
}
//Other if statements if you want to keep an eye out for other keyPresses
}
[edit] I just remembered you might be also considering the shortcuts, in wich case the Button1.Text property should be marked &Button1, this way the "B" would be underlined and accept the alt+B shortcut to execute the button click event.
The & symbol is set before the letter you want for the shortcut, make sure you dont use the same letter for various buttons.
You wouldn't write the code in Form.Load() if you want it to happen in response to a keyboard event. That event occurs (and the code inside of it is executed) when your form first loads (appears on screen).
How about handling the KeyPress event and writing the code in that method, instead? Your form has one of those events, too.
Sample code:
private void Form1_KeyPress(object sender, KeyPressEventArgs e)
{
Button1.PerformClick();
}
The PerformClick method will generate a Click event for a Button control. You can handle that Click event in a similar way:
private void Button1_Click(object sender, EventArgs e)
{
// do something in response to the button being clicked
// ...
MessageBox.Show("Button clicked!");
}
If this event-handling stuff is confusing to you, make sure that you pick up a good book on programming in C# and/or the .NET Framework so that you learn it well. It's very important and not something to skip!
You have to enable KeyPreview property on the form, then you have to implements the KeyPress event directly on the form :
Form1.KeyPress +=new KeyPressEventHandler(Form1_KeyPress);
private void Form1_KeyPress(object sender, KeyPressEventArgs e) {
if(e.KeyCode == someKey) {
button1.performclick();
}
}
private void Form_KeyDown(object sender, KeyEventArgs e)
{
if(e.KeyCode == Keys.Left)
{
// Do your hang job
Button_Click(sender, EventArgs.Empty);
}
}
You need to subscribe to the events of interest and process them after. But before you need to read and study how to do that. It's a not a difficult issue in C#.
http://msdn.microsoft.com/en-us/library/ms171534.aspx
One time subscribed to the events create a function that you can call from button click and from keydown.
I'm working on a simple WinForms application for a public school where users can identify themselves by entering either their network IDs (which are not protected information) or their system IDs (which are protected information). I want to switch to a password character when the program detects a system ID (which is working just fine); however, when I do this, my application also fires the textbox's Leave event, which tells users to fix a problem with the login data...before there's even a problem.
Here's my code:
void login_TextChanged(object sender, EventArgs e)
{
login.UseSystemPasswordChar = login.Text.StartsWith(<prefix-goes-here>);
}
private void login_Leave(object sender, EventArgs e)
{
if (login.Text.StartsWith(<prefix-goes-here>) && login.Text.Length != 9)
{
signInError.SetError(login, "Your System ID must be nine digits.");
login.BackColor = Color.LightPink;
}
else if (login.Text.IsNullOrWhiteSpace())
{
signInError.SetError(login, "Please enter your username or System ID.");
login.BackColor = Color.LightPink;
}
else
{
signInError.SetError(login, string.Empty);
login.BackColor = Color.White;
}
}
Ultimately, I don't know that this will cause a ton of problems, and I could move this validation step to the Click event of the sign in button on my form, but I'd rather do validation piece-by-piece if possible.
Putting the TextBox inside a GroupBox does reproduce that behavior-- which is odd.
If you want to keep your GroupBox, here is a work around:
private void login_TextChanged(object sender, EventArgs e)
{
login.Leave -= login_Leave;
login.UseSystemPasswordChar = login.Text.StartsWith(<prefix-goes-here>);
login.Leave += login_Leave;
}
For whatever reason, the Leave event fires when the login TextBox is inside a GroupBox control. Replacing the GroupBox with a simple Label control prevented the code within the TextChanged event from firing the Leave event.
Yes, this is a quirk of the UseSystemPasswordChar property. It is a property that must be specified when the native edit control is created (ES_PASSWORD). Changing it requires Winforms to destroy that native control and recreate it. That has side-effects, one of them is that the focus can't stay on the textbox since the window disappears. Windows fires the WM_KILLFOCUS notificaiton.
Being inside a GroupBox is indeed a necessary ingredient, Winforms doesn't suppress the Leave event when it gets the notification. Bug.
Many possible fixes. You could set a flag that the Leave event handler can check to know that it was caused by changing the property.
I have a RichTextBox that allows the user to type and edit and insert some complex UIElements that are wrapped in InlineUIContainer. The problem is when the user tries to delete/backspace one of the InlineUIContainers. I would like to disable deleting of these InlineUIContainers and I have another way for the user to delete them.
I have tried intercepting the deletion with the KeyEvents/PreviewKeyEvents, the textchanged event, the unload event of the UIElement. So far, they are not working because the deletion is trying to execute before those events are called.
Try PreviewKeyDown:
private void RichTextBox_PreviewKeyDown(object sender, KeyEventArgs e)
{
if (e.Key == Key.Delete)
{
e.Handled = true;
}
}
using c# winforms vs2008
I've got a textbox on a form with a method being called from the textBox1_Leave event. The method takes the contents of the textbox in question and populates other textboxes based on the contents.
My problem is that is the user has focus on the text box then clicks the button to close the form (calling this.close) then the form does not close because the textbox leave event gets fired.
If the textbox does not have focus on form close then the form closes fine.
If however a user closes the form by clicking the little X close icon in the top corner the it closes fine all the time with out the textbox leave event being fired.
How can I duplicate the X close functionality so that I can always close the form without the textbox leave event being fired?
The simplest solution is going to be to check which control is actually focused before doing your post-processing - but you can't do it in the Leave handler, because the focus will still be on the text box at that point.
Instead, you need to move your logic to the LostFocus event, which is not in the designer. You'll have to wire it up at runtime:
public class Form1 : Form
{
public Form1()
{
InitializeComponent();
textBox1.LostFocus += new EventHandler(textBox1_LostFocus);
}
private void textBox1_LostFocus(object sender, EventArgs e)
{
if (closeButton.Focused)
return;
// Update the other text boxes here
}
}
The LostFocus event happens to fire after the new control receives focus.
Clarification - you might find that it works by putting this logic in the Leave event - if the focus is changed by the mouse. If the keyboard is used instead, you'll get the wrong behaviour. LostFocus is reliable in both cases - the focused control will always be the "new" control. This is documented on MSDN: Order of Events in Windows Forms.
Incidentally, the reason why you're not having this problem with the "red X" is that the X is not actually a control that can receive focus, it's part of the window. When the user clicks that, it's not causing the text box to lose focus, and therefore isn't causing the Leave event to fire.
Another approach:
Use the textbox's validating event instead of it's leave event, then change the button's CausesValidation property to false. You will also have to set the textbox to not cause validation in the button's click event so the validating event will not fire when the form is closing (thanks to #Powerlord for pointing this out).
private void button1_Click(object sender, EventArgs e)
{
this.textBox1.CausesValidation = false;
this.Close();
}
You could also handle the FormClosing event and make sure the e.Cancel argument does not get set to true by the validating events on the other controls on the form. I think they will be fired off before the FormClosing event.
private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
if (e.CloseReason == CloseReason.UserClosing)
{
e.Cancel = false;
return;
}
}
you can check to see which control has just got focus.
private void textBox1_Leave(object sender, EventArgs e)
{
if (btnClose.Focused)
return;
// go from here
}
Just check if the form owning the textbox is disposing? If it's getting closed, it's disposing. If it's disposing you could simply end the pesky 'leave' event without doing anything. I didn't check it and forgive me, I'm choked on a project of my own so and I was searching myself, so I don't think I'll have time for that.
private void GuiltyTextBox_Leave(object sender, EventArgs e) {
Form formOwningTheTextBox=(Form)((Control)sender).TopLevelControl;
if (formOwningTheTextBox.Disposing || formOwningTheTextBox.IsDisposed) return;
.......
}
I just believe this is going to work with minimum effort and wanted to send a quick answer before I resume searching my own answer.
Write Following line of code in text box leave event on top
if me.closing then
return
end if