Is Ctrl key pressed?

[=?Utf-8?B?QWxleCBLLg==?=]

Hi all

When processing datagrid's MouseDown event, I need to know if Ctrl key is
currently pressed. Is there any way to check this?
It would help if I had keyUp and KeyDown events for Ctrl key ...

Thank you

[Nicholas Paldino [.NET/C# MVP]]

Alex,

You could hook up to the KeyDown and KeyUp events, and check the Control
parameter of the KeyEventArgs instance that is passed to those methods. You
can then store that value in a flag that is accessible to your mouse click
handler. In your handler, you would check if the value is set. If it is,
you know the user is holding down the control key.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Alex K." <Al***@discussi ons.microsoft.c omwrote in message
news:3E******** *************** ***********@mic rosoft.com...

Hi all

When processing datagrid's MouseDown event, I need to know if Ctrl key is
currently pressed. Is there any way to check this?
It would help if I had keyUp and KeyDown events for Ctrl key ...

Thank you

[Gregg Walker]

Alex - You may simply use the ModifierKeys property of your form to check if
the Ctrl Key is pressed down.

i.e. ...

if((ModifierKey s & Keys.Control) == Keys.Control)
{
.... do something
}

--
Gregg Walker

[Brian Schwartz]

Yes, this will do it. I recommend grabbing a copy of ModifierKeys as soon as
the procedure starts, and then checking the copy throughout your procedure
as needed. On the off chance that your procedure is long-running, this will
avoid a situation where the user has long since let go of the key, even
though it was pressed at the actual time of the click.

--
Brian Schwartz
FishNet Components
http://www.fishnetcomponents.com
Fish Grid .NET Light: Powerful Layouts for Small Datasets
"Gregg Walker" <xy***@newsgrou p.nospamwrote in message
news:OI******** ******@TK2MSFTN GP03.phx.gbl...

Alex - You may simply use the ModifierKeys property of your form to check
if the Ctrl Key is pressed down.

i.e. ...

if((ModifierKey s & Keys.Control) == Keys.Control)
{
... do something
}

--
Gregg Walker

[Peter Duniho]

On Fri, 18 May 2007 13:25:23 -0700, Brian Schwartz
<ow***@fishnetc omponentswos.co mwrote:

Yes, this will do it. I recommend grabbing a copy of ModifierKeys as
soon as the procedure starts, and then checking the copy throughout your
procedure as needed. On the off chance that your procedure is
long-running,
this will avoid a situation where the user has long since let go of the
key,
even though it was pressed at the actual time of the click.

Are you sure that's a concern? The docs are not clear about this, and
there are multiple ways in the underlying native Windows API to get the
information. Only if it's effectively calling GetAsyncKeyStat e() would it
be necessary to get a copy as soon as you enter the event handler.

I haven't been able to prove to myself that it's *not* necessary, but I'm
curious if you know for sure that it is. It seems to me that given the
design of .NET, it would make more sense for the ModifierKeys property to
act more like GetKeyState() or even return the state of the flags passed
to the mouse down messages (WM_LBUTTONDOWN , etc.)

Thanks,
Pete

[Nicholas Paldino [.NET/C# MVP]]

This is why I recommended setting the state when the control button was
pressed down, and changing that state when it was released. This way, you
don't have that concern.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Fri, 18 May 2007 13:25:23 -0700, Brian Schwartz
<ow***@fishnetc omponentswos.co mwrote:

>Yes, this will do it. I recommend grabbing a copy of ModifierKeys as
soon as the procedure starts, and then checking the copy throughout your
procedure as needed. On the off chance that your procedure is
long-running,
this will avoid a situation where the user has long since let go of the
key,
even though it was pressed at the actual time of the click.

Are you sure that's a concern? The docs are not clear about this, and
there are multiple ways in the underlying native Windows API to get the
information. Only if it's effectively calling GetAsyncKeyStat e() would it
be necessary to get a copy as soon as you enter the event handler.

I haven't been able to prove to myself that it's *not* necessary, but I'm
curious if you know for sure that it is. It seems to me that given the
design of .NET, it would make more sense for the ModifierKeys property to
act more like GetKeyState() or even return the state of the flags passed
to the mouse down messages (WM_LBUTTONDOWN , etc.)

Thanks,
Pete

[Peter Duniho]

On Fri, 18 May 2007 18:35:38 -0700, Nicholas Paldino [.NET/C# MVP]
<mv*@spam.guard .caspershouse.c omwrote:

This is why I recommended setting the state when the control button
was pressed down, and changing that state when it was released. This
way, you don't have that concern.

That's fine. However, it seems to me that the behavior of the
ModifierKeys property should be well-defined. In fact, I suspect that it
*is* well-defined, and just poorly documented.

I'm asking if anyone knows what the well-defined behavior actually is.

It's well and good to write code defensively, especially in absence of
good documentation, but you shouldn't have to in this case, and I'd like
to know what the answer is.

Pete

[Nicholas Paldino [.NET/C# MVP]]

Peter,

The ModifierKeys property makes a call to GetKeyState, so you can call
it repeatedly throughout an event handler and get the same result.

Of course, this is an implementation detail, so counting on it would be
a bad idea.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Fri, 18 May 2007 18:35:38 -0700, Nicholas Paldino [.NET/C# MVP]
<mv*@spam.guard .caspershouse.c omwrote:

> This is why I recommended setting the state when the control button
was pressed down, and changing that state when it was released. This
way, you don't have that concern.

That's fine. However, it seems to me that the behavior of the
ModifierKeys property should be well-defined. In fact, I suspect that it
*is* well-defined, and just poorly documented.

I'm asking if anyone knows what the well-defined behavior actually is.

It's well and good to write code defensively, especially in absence of
good documentation, but you shouldn't have to in this case, and I'd like
to know what the answer is.

Pete