How to capture key

[Larry Smith]

Hi there,

Can someone enlighten me on how to trap a keystroke in my "PropertyGr id"
override. I see functions or properrites at the control or form level
called:

OnKeyDown
OnKeyPress
OnKeyUp
OnPreviewKeyDow n
ProcessKeyPrevi ew
ProcessDialogKe y
ProcessCmdKey
KeyPreview
IsInputKey

and there are probably more. I've overrided "OnKeyDown( )" in my derived
"PropertyGr id" class but it's not being called. Some others are called
however such as "ProcessCmd Key" but I need to understand what's going on
here (since I suspect that "OnKeyDown( )" is really the correct function).
Can anyone point me in the right direction. Thanks.

[VisualHint]

Hello Larry,

the MS PropertyGrid has an internal grid and this is this one that
receives the keyboard events. If you really want to have a handler for
those events, you can access the internal grid (type is
System.Windows. Forms.PropertyG ridInternal.Pro pertyGridView) with
myPropGrid.Cont rols[2]. But depending on your needs, this can be
tricky to play inside the private parts of the grid.

Best regards,

Nicolas Cadilhac @ VisualHint (http://www.visualhint.com)
Home of Smart PropertyGrid for .Net and MFC
Microsoft PropertyGrid Resource List - http://www.propertygridresourcelist.com
On Apr 12, 10:47 am, "Larry Smith" <no_spam@_nospa m.comwrote:

Hi there,

Can someone enlighten me on how to trap a keystroke in my "PropertyGr id"
override. I see functions or properrites at the control or form level
called:

OnKeyDown
OnKeyPress
OnKeyUp
OnPreviewKeyDow n
ProcessKeyPrevi ew
ProcessDialogKe y
ProcessCmdKey
KeyPreview
IsInputKey

and there are probably more. I've overrided "OnKeyDown( )" in my derived
"PropertyGr id" class but it's not being called. Some others are called
however such as "ProcessCmd Key" but I need to understand what's going on
here (since I suspect that "OnKeyDown( )" is really the correct function).
Can anyone point me in the right direction. Thanks.

[Larry Smith]

the MS PropertyGrid has an internal grid and this is this one that

receives the keyboard events. If you really want to have a handler for
those events, you can access the internal grid (type is
System.Windows. Forms.PropertyG ridInternal.Pro pertyGridView) with
myPropGrid.Cont rols[2]. But depending on your needs, this can be
tricky to play inside the private parts of the grid.

Thanks for the feedback. Are you saying that this particular control doesn't
follow the normal (and expected) rules IOW. I'm not sure why they would do
this since it's abnormal to say the least. In any case, if you know this for
a fact (have you confirmed it with MSFT?) then I'll have to rely on
"ProcessCmdKey( )" instead. I'd rather not rely on undocumented techniques.

On a completely unrelated matter however, I know that individual
"PropertyGr id" rows can't be colorized. Do you know a way to pull this off
even if I have to rely on undocumented techniques. I've looked into it and
can't find a way so far (since there seems to be no stable row-based window
behind the scenes until the user actually starts editing the row). Note that
I'm a very experienced C++ developer so hacking into it won't be a problem
if you can get me started (it's a necessary evil I need to explore). Thanks.

[VisualHint]

Hello Larry,

Why do you say it's abnormal? The internal grid has the focus so this
is absolutely normal that it gets the keyboard events.
Indeed I think you're better to rely on a public solution. But you
should override ProcessKeyPrevi ew instead of ProcessCmdKey which is
more intended for command keys (accelerator and menu shortcuts).
ProcessKeyPrevi ew gives the opportunity to the parent to process the
key before or instead of the child.

Concerning colors, you won't be able to change them on a per property
basis. Sorry for the plug but only a solution like Smart PropertyGrid
will let you customize most of the aspects of the grid. Getting into
the internals of the MSPG has its limits.

Best regards,

Nicolas Cadilhac @ VisualHint (http://www.visualhint.com)
Home of Smart PropertyGrid for .Net and MFC
Microsoft PropertyGrid Resource List - http://www.propertygridresourcelist.com
On Apr 12, 2:59 pm, "Larry Smith" <no_spam@_nospa m.comwrote:

the MS PropertyGrid has an internal grid and this is this one that
receives the keyboard events. If you really want to have a handler for
those events, you can access the internal grid (type is
System.Windows. Forms.PropertyG ridInternal.Pro pertyGridView) with
myPropGrid.Cont rols[2]. But depending on your needs, this can be
tricky to play inside the private parts of the grid.

Thanks for the feedback. Are you saying that this particular control doesn't
follow the normal (and expected) rules IOW. I'm not sure why they would do
this since it's abnormal to say the least. In any case, if you know this for
a fact (have you confirmed it with MSFT?) then I'll have to rely on
"ProcessCmdKey( )" instead. I'd rather not rely on undocumented techniques.

On a completely unrelated matter however, I know that individual
"PropertyGr id" rows can't be colorized. Do you know a way to pull this off
even if I have to rely on undocumented techniques. I've looked into it and
can't find a way so far (since there seems to be no stable row-based window
behind the scenes until the user actually starts editing the row). Note that
I'm a very experienced C++ developer so hacking into it won't be a problem
if you can get me started (it's a necessary evil I need to explore). Thanks.

[Larry Smith]

Thanks again for the feedback.

Why do you say it's abnormal? The internal grid has the focus so this
is absolutely normal that it gets the keyboard events.

I say it's abnormal because an "OnKeyDown( )" override should be called
AFAIK. It's a published function which originates from the "Control" base
class no less. Unless I'm missing something I don't see why it's not being
called.

Indeed I think you're better to rely on a public solution. But you
should override ProcessKeyPrevi ew instead of ProcessCmdKey which is
more intended for command keys (accelerator and menu shortcuts).
ProcessKeyPrevi ew gives the opportunity to the parent to process the
key before or instead of the child.

My control is self-contained so it needs to handle its own keystrokes. I've
already played with "ProcessKeyPrev iew()" but will take another look. Since
it's low-level however I figured that "OnKeyDown( )" was likely more
appropriate. The variety of keystroke functions/properties available is
bewildering given the absence of adequate documentation.

Concerning colors, you won't be able to change them on a per property
basis. Sorry for the plug but only a solution like Smart PropertyGrid
will let you customize most of the aspects of the grid. Getting into
the internals of the MSPG has its limits.

You're right of course and I'm puzzled why MSFT never gave us control over
this (color, font, etc.). It's basic. It's also particularly important for
my own app so I'll likely replace "PropertyGr id" by the second release
(first release is pending this fall). Note that I didn't pursue your own
control for a variety of reasons not the least of which is that it came to
my attention too late. I also require localization in potentially many
languages. What languages does yours support? Note BTW (FYI) that Mark
Rideout (manager of the "DataGridVi ew" control at MSFT) has also posted
this:

http://blogs.msdn.com/markrideout/ar...08/510700.aspx

It's unofficial and likely needs work (haven't looked at it in detail) but
it serves as an excellent starting point to replace the "PropertyGr id"
(IMO). Thanks again for your help.

[VisualHint]

No, OnKeyDown() shouldn't be called for the PropertyGrid. The
PropertyGrid acts as a container (the PropertyGrid class) and is
composed of the toolstrip, the internal grid and the label (comment
area). When the internal grid has the focus, it receives the keyboard
events and handle them. The parent container's virtual methods like
OnKeyDown won't be called simply because the keystrokes are not
directed to it. To be aware of the keys typed, you can override
ProcessKeyPrevi ew or subscribe to the events of the internal grid
(Controls[2].KeyDown += ......). But not that in the second
possibility, the keys will still be handled by the child. In the first
solution you can "eat" the keys messages.

So, this is what happens normally. However I agree that MS should have
provided a way to make the container aware of these events in a more
"natural" way. FYI, SPG forwards the events automatically to the
parent.

Concerning localization, neither SPG or MSPG support a particular
language. This is up to the client application to load the correct
strings and to supply them via Description and DisplayName attributes.
Note that SPG also enables on the fly modification of these
properties.

Hope that helps.

Best regards,

Nicolas Cadilhac @ VisualHint (http://www.visualhint.com)
Home of Smart PropertyGrid for .Net and MFC
Microsoft PropertyGrid Resource List - http://www.propertygridresourcelist.com
On Apr 12, 5:43 pm, "Larry Smith" <no_spam@_nospa m.comwrote:

Thanks again for the feedback.

Why do you say it's abnormal? The internal grid has the focus so this
is absolutely normal that it gets the keyboard events.

I say it's abnormal because an "OnKeyDown( )" override should be called
AFAIK. It's a published function which originates from the "Control" base
class no less. Unless I'm missing something I don't see why it's not being
called.

Indeed I think you're better to rely on a public solution. But you
should override ProcessKeyPrevi ew instead of ProcessCmdKey which is
more intended for command keys (accelerator and menu shortcuts).
ProcessKeyPrevi ew gives the opportunity to the parent to process the
key before or instead of the child.

My control is self-contained so it needs to handle its own keystrokes. I've
already played with "ProcessKeyPrev iew()" but will take another look. Since
it's low-level however I figured that "OnKeyDown( )" was likely more
appropriate. The variety of keystroke functions/properties available is
bewildering given the absence of adequate documentation.

Concerning colors, you won't be able to change them on a per property
basis. Sorry for the plug but only a solution like Smart PropertyGrid
will let you customize most of the aspects of the grid. Getting into
the internals of the MSPG has its limits.

You're right of course and I'm puzzled why MSFT never gave us control over
this (color, font, etc.). It's basic. It's also particularly important for
my own app so I'll likely replace "PropertyGr id" by the second release
(first release is pending this fall). Note that I didn't pursue your own
control for a variety of reasons not the least of which is that it came to
my attention too late. I also require localization in potentially many
languages. What languages does yours support? Note BTW (FYI) that Mark
Rideout (manager of the "DataGridVi ew" control at MSFT) has also posted
this:

http://blogs.msdn.com/markrideout/ar...08/510700.aspx

It's unofficial and likely needs work (haven't looked at it in detail) but
it serves as an excellent starting point to replace the "PropertyGr id"
(IMO). Thanks again for your help.

[Larry Smith]

No, OnKeyDown() shouldn't be called for the PropertyGrid. The

PropertyGrid acts as a container (the PropertyGrid class) and is
composed of the toolstrip, the internal grid and the label (comment
area). When the internal grid has the focus, it receives the keyboard
events and handle them. The parent container's virtual methods like
OnKeyDown won't be called simply because the keystrokes are not
directed to it. To be aware of the keys typed, you can override
ProcessKeyPrevi ew or subscribe to the events of the internal grid
(Controls[2].KeyDown += ......). But not that in the second
possibility, the keys will still be handled by the child. In the first
solution you can "eat" the keys messages.

Ok, thanks for the primer. While I don't agree with this behaviour (it's
inconsistent and counterintuitiv e) we live in a world of imperfection.

So, this is what happens normally. However I agree that MS should have
provided a way to make the container aware of these events in a more
"natural" way. FYI, SPG forwards the events automatically to the
parent.

How easy would it be to port my code to your grid. Is it compatible with the
native grid (can we feed it the same way) or am I'm faced with a lot of
redevelopment. Note that I've rolled my own custom "TypeConver ter" and
"TypeDescriptio nProvider" classes (overrding "GetProperties( )" where req'd)
and I don't want to tear it all apart at this stage (since it's working
now).

Concerning localization, neither SPG or MSPG support a particular
language. This is up to the client application to load the correct
strings and to supply them via Description and DisplayName attributes.
Note that SPG also enables on the fly modification of these
properties.

Ok, thanks. I didn't know whether your grid had any of its own native
strings or not.

[VisualHint]

Larry,

if you want to know more about SPG I propose that you contact me
through the VisualHint helpdesk. I don't think this is the proper
place here... ;)

Best regards,

Nicolas Cadilhac @ VisualHint (http://www.visualhint.com)
Home of Smart PropertyGrid for .Net and MFC
Microsoft PropertyGrid Resource List - http://www.propertygridresourcelist.com
On Apr 12, 7:33 pm, "Larry Smith" <no_spam@_nospa m.comwrote:

No, OnKeyDown() shouldn't be called for the PropertyGrid. The
PropertyGrid acts as a container (the PropertyGrid class) and is
composed of the toolstrip, the internal grid and the label (comment
area). When the internal grid has the focus, it receives the keyboard
events and handle them. The parent container's virtual methods like
OnKeyDown won't be called simply because the keystrokes are not
directed to it. To be aware of the keys typed, you can override
ProcessKeyPrevi ew or subscribe to the events of the internal grid
(Controls[2].KeyDown += ......). But not that in the second
possibility, the keys will still be handled by the child. In the first
solution you can "eat" the keys messages.

Ok, thanks for the primer. While I don't agree with this behaviour (it's
inconsistent and counterintuitiv e) we live in a world of imperfection.

So, this is what happens normally. However I agree that MS should have
provided a way to make the container aware of these events in a more
"natural" way. FYI, SPG forwards the events automatically to the
parent.

How easy would it be to port my code to your grid. Is it compatible with the
native grid (can we feed it the same way) or am I'm faced with a lot of
redevelopment. Note that I've rolled my own custom "TypeConver ter" and
"TypeDescriptio nProvider" classes (overrding "GetProperties( )" where req'd)
and I don't want to tear it all apart at this stage (since it's working
now).

Concerning localization, neither SPG or MSPG support a particular
language. This is up to the client application to load the correct
strings and to supply them via Description and DisplayName attributes.
Note that SPG also enables on the fly modification of these
properties.

Ok, thanks. I didn't know whether your grid had any of its own native
strings or not.

[Larry Smith]

if you want to know more about SPG I propose that you contact me

through the VisualHint helpdesk. I don't think this is the proper
place here... ;)

Yes, this isn't the proper venue. Will be in touch in the near future.
Thanks again for your help here.