K
Kevin Frey
We have a dialog containing a treeview on the left displaying groups
and a grid on the right, displaying data records belonging to the
group.
We are using Shift-F2 to view the full details of the record displayed
in the grid.
We have turned on KeyPreview so that if focus is on the treeview,
Shift-F2 can still be intercepted by the form. If the grid does not
have a selected row the Shift-F2 throws up a message box "No Row
Selected".
The strange behaviour I am seeing is that the form has not logically
handled the keypress (despite throwing up the message box).
The tree-view subsequently sees a KeyDown event fire for the same key,
but this time the ctrl/alt/shift state of the KeyEventArgs are all
false.
We use F2 to rename a group within the tree, and hence the user
presses Shift-F2, gets the message-box, and the tree subsequently goes
into "edit mode" to change the group name.
I have played around with this, and have noticed that after pressing
Shift-F2 I have released both the Shift and F2 keys (as one would
normally do). The message box appears, and after clicking OK (or
hitting Enter) the tree view goes into Edit mode.
However, if I continue to keep the shift key held down when I click
the OK button on the message box, the tree view does not go into edit
mode, presumably because the KeyDown event to the tree view is now
getting the shift flag correctly set.
The .NET documentation says the Shift/Control/Alt properties indicate
if the key *was* pressed, so it should be bound to whatever state
existed at the time the key was pressed.
Is this a bug? It looks like KeyEventArgs is interrogating the
shift/ctrl/alt state twice or it is interrogating that state in real
time (eg. GetKeyState).
I guess the argument here (and perhaps the workaround) is whether
throwing up a messagebox implies that I have *handled* the key in some
way and should have indicated that fact, at which point the tree-view
would not have received the key?
and a grid on the right, displaying data records belonging to the
group.
We are using Shift-F2 to view the full details of the record displayed
in the grid.
We have turned on KeyPreview so that if focus is on the treeview,
Shift-F2 can still be intercepted by the form. If the grid does not
have a selected row the Shift-F2 throws up a message box "No Row
Selected".
The strange behaviour I am seeing is that the form has not logically
handled the keypress (despite throwing up the message box).
The tree-view subsequently sees a KeyDown event fire for the same key,
but this time the ctrl/alt/shift state of the KeyEventArgs are all
false.
We use F2 to rename a group within the tree, and hence the user
presses Shift-F2, gets the message-box, and the tree subsequently goes
into "edit mode" to change the group name.
I have played around with this, and have noticed that after pressing
Shift-F2 I have released both the Shift and F2 keys (as one would
normally do). The message box appears, and after clicking OK (or
hitting Enter) the tree view goes into Edit mode.
However, if I continue to keep the shift key held down when I click
the OK button on the message box, the tree view does not go into edit
mode, presumably because the KeyDown event to the tree view is now
getting the shift flag correctly set.
The .NET documentation says the Shift/Control/Alt properties indicate
if the key *was* pressed, so it should be bound to whatever state
existed at the time the key was pressed.
Is this a bug? It looks like KeyEventArgs is interrogating the
shift/ctrl/alt state twice or it is interrogating that state in real
time (eg. GetKeyState).
I guess the argument here (and perhaps the workaround) is whether
throwing up a messagebox implies that I have *handled* the key in some
way and should have indicated that fact, at which point the tree-view
would not have received the key?