I am making a game, and to open up and close the store, you press S. While in the store, you have six different choices to buy from, but they are all buttons.
However, once you buy something, the focus is no longer on the form, but on the button, and the key down event is part of the form, therefore, because the focus gets switched from the form to the button, the key down event no longer works, and disables you from closing the store and continuing on with the game.
My question is how to set the focus back to a form once a button is press? I started out with visual basic, and the code would be something along the lines of form1.setfocus, but its totally different in c#.
I have tried Activating the form, .focus, a lot, and nothing seems to be setting the focus back to the form. Help would be greatly appreciated.
Form1.focus();
But I think, to get keyboard events on Form itself, you need KeyPreview set to true for the Form so that Form gets Keys first and then other controls.
Try:
form.Focus();
MSDN:
The Focus method returns true if the control successfully received input focus. The control can have the input focus while not displaying any visual cues of having the focus. This behavior is primarily observed by the nonselectable controls listed below, or any controls derived from them.
Tell me more
You can add the key down event to the buttons too.
I'm relatively new to C# and I want to know how can I press a key on my keyboard say the Q key and have it preform a list of functions?
I want to form a list of function under neath it. Anybody have any idea how to do this? thanks
//Something like this
if keyboard_down(Q)
{
//Do events here
}
I know this isn't the right function but that is basically what i want it to do. Winforms
You didn't mention which technology you work with.
I will assume that you are using Winforms.
In order to react to Key Press event you need to use Control.OnKeyPress - See here
See also this example which shows how to handle 'enter' key press
Depends on the way you want it.
Do you want them to fire while the form got focus or even without any focus to the form?
With focus:
Click your form in the form-designer and then go to the properties-tab. Click that little lightning bolt on top of it. There are a lot of events in that list. Double click "Keypress" and it will create an event automaticly and open the right code-snipped for you.
Depending on the focus you want, you can also mark controlls inside the form designer and then create the keypress event.
Without focus:
This would be a bit more difficultly. Here you would need to use a global keyboard hook to permanently grab pressed keys. Google for "c# keyboard hook". There are some examples out there.
I have succesfully replaced the Windows Shell following the approach given in this SO question.
However, I have detected that the first key press is lost and is a bit of an annoyance for the user. The solution we have tried is to activate the form in the OnShown event:
private void OnShownLoginForm(object z_sender, EventArgs z_e)
{
Activate();
m_loginTextBox.Focus();
}
But this hasn't solved the problem. Do you have any clue of what is happening?
You could try using the System.Windows.Forms.SendKeys Class (MSDN Documentation) to send a key press event to the form when in the Form Load event. If that doesn't help, try sending the keyboard events in the Form.Shown event since Form.Shown is the last event in the form start-up process.
Sounds like something caused by maybe another control getting focus first. Does the textbox have a taborder, and can you set it to 0? Focus should then be on it after the form loads.
Otherwise try creating a new form to test with, it really doesn't seem reproducible.
I do not know if it is related but I had a similar problem where the tabindex property of a webform did not work by pressing the TAB key, after focusing on the first input at page load, until the user first clicked on the form with the mouse.
I did not have access to the source code so I tried solving it with javascript.
Until the first mouse click, all keyboard strokes, including the TAB key, activated the keypress event, TAB key was undetected by keydown/keyup on page load.
I learned that the TAB key activated the keypress event and I could access the keycode through it. simply registering the keypress event and manually switching to the next input with jQuery worked.
after the first mouse click the form behaved as expected, TAB key was no longer caught by keypress event.
here is a code sample:
function tabNext(e){
if(e.keyCode == 9){
// do work
}
}
$('input').keypress(tabNext);
HI,
I have a form in C# app. On this form I capture a KeyDown event Alt+U which will open a second form. In the second form I have a toolStripButton with shortcutkey Alt+U (the same which I used to open the form with) which prints a document. Now, my problem is when I open the second form It will automatically trigger the event of clicking toolstripbutton since it has the same shortcutkey as I used to open the form with. How can I prevent this from happen.
Regards Johan
This doesn't answer your question, but you really should think about making two different shortcut keys for these two very different actions. Having two identical shortcut keys that do two entirely different actions is very confusing IMO.
To answer your question though, I would have some property on the second form like "ShouldRaise" or something, and only raise the Alt + U event in the second form if that flag is true. Set it to false initially, but then in the KeyUp in the first form, set it to true.
Would it not just be easier to change the shortcut of one to something else? I agree with BFree its not the best design have the same shortcut for 2 completely different functions. All shortcuts/accelerator keys should be unique.
Why not change the shortcut for the form page changing to something like:
Ctrl+Right (Go to next page)
Ctrl+Left (Go to previous page)
On the second form do you actually have a ToolStripMenuItem instead? (a ToolStripButton doesn't have the ShortcutKeys property).
Do you instantiate a new form when the user presses Alt-U on the parent form?
Did you check the sender object on the handler that prints the document to see if it was the parent form?
Can't seem to reproduce your problem; a little explaining would help.
Another easy solution is to do some check of what form you are in from the event listener. You could just return inside the event handler inside your second form.
Again not the most elegant solution but should be a decent fix.
Rep steps:
create example .NET form application
put a TextBox on the form
wire a function up to the TextBox's Enter event
When you run this application, the Control.Enter event fires when focus first goes to the TextBox. However, if you click away into another application and then click back into the test application, the event will not fire again.
So moving between applications does not trigger Enter/Leave.
Is there another alternative Control-level event that I can use, which will fire in this scenario?
Ordinarily, I would use Form.Activated. Unfortunately, that is troublesome here because my component is hosted by a docking system that can undock my component into a new Form without notifying me.
What are you trying to do in the Enter event?
I can't find another control-level event that fires in your example program but when my test app does regain focus, the control that last had focus still has it.
Interesting question but it needs a little more context.
If I try your example and click outside the control on another window, desktop, etc, I can get the Got and Lost Focus events to fire, but if you're only trying to click within a form or a control with only 1 control, these event will never be fired because it is the only thing to focus on. Neither will Entered or left, unless you change the dynamics or overload the controls, you cannot get this to happen
In your example, I think you need another control. The reason being is that the first control (tabIndex 0) is the one with focus. With no other control to switch focus to, this control will always be focused, and therefore can never be entered. Switching to another application or form will not change the focus or active control in this form so when you return you will still not get the event fired.
With added controls control.entered should work fine. If this is your only control, why not call the event on formLoad, or TextChanged, when the form gets focus?
Thanks, I'll give some background.
My control is a UserControl that contains a grid and a toolbar. A user will typically launch several of these controls to view different slices of the system's data.
There are several keyboards shortcuts that can launch actions from the selected row in the current grid. However, it is a requirement that these keyboard shortcuts should apply not only to the currently focused grid. If the user is currently focused on one of the many other areas of the application, then this keyboard shortcut should still work, and it should be routed to the last focused grid.
So I wired a function to the Control.Enter event of my UserControl to basically say LastFocusedGrid = this.
And it would work, except for the docking and undocking...
See, these controls are hosted inside an application with docking features, somewhat similar to visual studio.
By default, the control launches as a tab within the main working area of the application, similar to the way a source file opens in visual studio.
However, the user can "rip out" a tab by grabbing the tab header and dragging it out of the main application. At this point, the application creates a new "float form" to host the control. Switching between the main application and this float form is the same as switching between apps, for the purposes of the Control.Enter and Form.Activated events.
At that point we have the "one control within a form" scenario simulated with the example application described in the original post.
Now, there are some ways around this. I could leverage the Form.Activated event, which DOES fire when switching between forms. If you add an event in the test application to the Form's Activated event, you will see that it works great.
The problem is that my UserControl's relationship with its parent Form is fluid, making the solution somewhat complicated. I tried wiring up to "this.ParentForm.Activated" which worked okay. The problem is when do you call this? What happens when you are undocked/redocked? I ended up with a nasty bunch of code with things like "previousParentForm" so that I could unhook from the old form, and then I was still facing the problem that the docking system doesn't notify me when my parent Form is being changed, so I was going to have to make a bunch of changes there, too.
These problems are not unsolvable, but if there is a simpler control-level "parent form was activated" event, then that would be a lot more elegant.
That's rather long, but I hope it clarifies the situation.
So when creating your grid, can you not set the KeyPressed, or KeyUp, etc. event? If so, all the grids can make use of the same event handler. Just make sure that when you get into the event handler to do something like:
Grid currentGrid = (Grid)sender;
Then you should be able to apply that block of code to any grid that gets sent in without having to worry about keeping track.
Since all the event handler really is, it's location is a mute point really as long as everything you need to execute it is accessible.
Frye, the problem is that the keyboard shortcuts should work no matter where the user is in the application. They are gloabl commands, handled at the top level, and then routed to the "last focused grid."
So handling the keystrokes at the grid level will not help.
To be more specific, assume user launches grids A, B, and C. But he also launches other controls X, Y, and Z that have nothing to do with my code.
User clicks on A, then on C. Then he clicks on Y, then on Z. With focus on Z, he hits my keyboard shortcut. In this case, grid C should respond since it was the last grid the user was focused in.
It sounds like the issue that you're having is not directly related to the Enter event and more to the point, if you have controls "that have nothing to do with your code" then you really aren't looking at a control level event.
Guess I wasn't clear.
My control lives in a container application. So do other unrelated controls by other teams. Think of it like visual studio -- my control is the code editing tab, but there is also the pending changes list and the properties window, which cohabitate with the source files but aren't directly related.
The keyboard shortcut is handled by the container application. Then it should be routed to the last one of my controls that the user was focused on.
Maintaing this "LastFocusedGrid" reference is what I do in the Enter event.
If you want to see similar functionality at work in visual studio, try this:
open a few source files
navigate to the "Start Page" tab.
Hit Ctrl-F and search "current document" for some string
Notice that the serach feature auto-navigates to the LAST FOCUSED source file to perform the search.
So even though you weren't focused in the source file, the ctrl-F command was processed by visual studio and routed to the last focused source file tab.
Now try the same thing with Ctrl-G. It doesn't work unless you are focused directly in the source file.
My keyboard commands need to work like Ctrl-F here, not like Ctrl-G. That is why I don't just capture the keyboard events directly in my control.
Does that clarify or make things worse?
Have you tried just a simple Control.GotFocus?
in this example if you toggle between clicking the textboxes neither the enter or got focus will do as expected, however if you click the child forms instead both will behave as expected.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
namespace EnterBrokenExample
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Form Form1 = new Form();
Form c1 = new Form();
Form c2 = new Form();
Form1.IsMdiContainer = true;
c1.MdiParent = Form1;
c2.MdiParent = Form1;
c1.Show();
c2.Show();
TextBox tb1 = new TextBox();
c1.Controls.Add(tb1);
tb1.Enter += ontbenter;
tb1.Text = "Some Text";
tb1.GotFocus += ongotfocus;
TextBox tb2 = new TextBox();
c2.Controls.Add(tb2);
tb2.Enter += ontbenter;
tb2.Text = "some other text";
tb2.GotFocus += ongotfocus;
Application.Run(Form1);
}
static void ontbenter(object sender, EventArgs args)
{
if (!(sender is TextBox))
return;
TextBox s = (TextBox)sender;
s.SelectAll();
}
static void ongotfocus(object sender, EventArgs args)
{
if (!(sender is TextBox))
return;
TextBox s = (TextBox)sender;
s.SelectAll();
}
}
}