C# .Net Keyboard problem

[Brian Ward]

Hello
=====
I am trying to do a simple exercise using Visual Studio C#.
I have a form with one picturebox and some buttons.
I want to be able to control a picture box graphic using the keyboard
(especially arrow keys). All works well by using the Form1_KeyDown()
method .. until I add buttons to the form .. then the keyboard control
ceases to work.
I have looked for properties to change to give the form priority but
can't see anything.
Advice would be much appreciated.
TIA
===
Brian
===

 

[not_a_commie]

My advice is that you move your project to WPF. WPF doesn't have these
issues you're seeing because of their RoutedEvent model. It's much
easier, faster in panning the picture, and better all around.

 

[Smithers]

Not much to go on here, but Setting KeyPreview to true may help (if not
already set to true).

http://msdn2.microsoft.com/en-us/library/system.windows.forms.form.keypreview.aspx

-HTH

 

[Peter Duniho]

Hello
=====
I am trying to do a simple exercise using Visual Studio C#.
I have a form with one picturebox and some buttons.
I want to be able to control a picture box graphic using the keyboard
(especially arrow keys). All works well by using the Form1_KeyDown()
method .. until I add buttons to the form .. then the keyboard control
ceases to work.

Probably because the Button controls have the focus when you are trying
use the keyboard, and so are getting the key events.

I have looked for properties to change to give the form priority but
can't see anything.

Sounds like you want the Form.KeyPreview property, set to "true". This
will cause the Form instance to receive all of the key events before
they are sent to the control that actually has focus. Set the "Handled"
property in the appropriate event args class if you actually handle the
key event, so that you don't get parallel handling of the key (ie the
form reacts to a key and some other control does at the same time).

I don't believe that your issue has anything to do with using WPF or
not. I can't imagine that given your specific question, rewriting your
project to use WPF just so that the form can get key events is an
appropriate solution.

Pete

 

[Brian Ward]

Thanks Peter (and Smithers) .. setting KeyPreview to true is a partial
solution.
This now seems to enable me to detect Keys such as U, D etc. but
strangely not the arrow keys.
I am using this code in the Form1_KeyDown() method:

string input = e.KeyData.ToString();

if (input == "Down" || input == "D")
{
y = y + 10;
} // etc.

Without the buttons, this used to work with both the "Down" arrow and
the "D" key .. now only the "D" works (when KeyPreview is set .. better
than nothing though!)
==
Brian
==

 

[Peter Duniho]

Thanks Peter (and Smithers) .. setting KeyPreview to true is a partial
solution.
This now seems to enable me to detect Keys such as U, D etc. but
strangely not the arrow keys.

Ah. Sorry...I should have paid closer attention in your original post
that you want to include arrow keys.

For those, they are handled as "dialog keys", unless the control getting
the key events returns true from the IsInputKey() method. I haven't
tried this myself, so you'll have to experiment a little. It's possible
that you can override IsInputKey() in your form, returning "true" for
the arrow keys.

But it's possible that even setting KeyPreview to "true" won't cause the
form's IsInputKey() method to be called (like I said, haven't tried it
myself). If so, you should be able to override ProcessDialogKey and
handle the arrow keys there.

Pete

 

[Peter Duniho]

string input = e.KeyData.ToString();

if (input == "Down" || input == "D")
{
y = y + 10;
} // etc.

Oh, and in addition to my other post...

I would strongly recommend just using the Keys constants, rather than
calling ToString() and then doing string comparisons. Doing so would be
much more efficient, in terms of code size, data size, and run-time
performance.

Pete

 

[Brian Ward]

Thanks Pete
=========
Overriding ProcessCmdKey() seems to do the job!
Returning true when arrow keys, etc. detected, false otherwise.
Thanks for your help.
==
Brian
==